View Poll Results: Did ToolkiT make the right choise?

Voters
44. You may not vote on this poll
  • Yes, if he thinks so.. After all he is the mod

    24 54.55%
  • No, Treo 270 is the way to go!

    6 13.64%
  • not sure/No opinion

    0 0%
  • He should have saved his money like his wife said

    14 31.82%
Page 3 of 4 FirstFirst 1234 LastLast
Results 41 to 60 of 68
  1. #41  
    Originally posted by ToolkiT

    Do you like salty licorice (or better know as 'zoute drop'? If not I doubt you have any dutch blood left in you
    Well, there's not only Double Salt licorice, but Triple Salt licorice...

    I eat the Zoute Drops sparingly; but those little licorice cats... now those I chow down on constantly. I'm not Dutch, though -- just worked with Dutch guys, and picked up several of their eating habits.

    Can you say Stroopwafels?
    Jeff Meyer

    "And he died like he lived: with his mouth wide open."
  2. #42  
    dkessler, forgive me if this sounds harsh, but I am all for the 'constraints on PalmOS developers.' Your (collectively, of course) code is going to bloat all to hell once those constraints have been removed, crippling any advantage the extra processing power and RAM would give. I, as an end user, am happy at the hoops you (collectively, again) have had to jump through, as it has made your apps as snappy as those being run on the PPC platform with triple the MHz. I understand where you're coming from (the attitude that there's more that can be done with more horsepower), but I see it as an unnecessary price increase that will yeild little or no discernable advantage over what I am doing now.
    -Joshua
    I've decided to become enigmatic.
  3. #43  
    Stroopwafels, zoute drop, zoete drop, edammer kaas, pitjeskaas, extra belegen goudsekaas, calve pindakaas, hagelslag, muisjes, bamie kruiden, nassi kruiden, beschuit, zoute haring, kroketten, frikandellen.

    I love Handyshopper2, I use it mostly to keep track of the shopping list (above) I send my mother every few months. I am glad that now they retired travel all over the world most of the year which means a visit or three at least every year. At the end of the month my new stock should be arriving ;-)

    Btw. I love extra zoute lappen (salmiak) but last year I couldn't find them anywhere. Wouldn't suprise me if the european parliament decided to put it on the list of forbidden goods because it's bad for something, like teeth, or so.
  4. #44  
    Originally posted by dkessler

    The APIs remain largely unchanged and PalmOS 5.0 applications are still compiled for the Dragonball processor and then executed via a Dragonball emulator running on the new ARM based devices.
    Dave, could you clarify this statement -- I'm confused. (I know -- it's not unusual for me.)

    Do you mean that:
    • The standard Palm applications (e.g., Address, MemoPad, HotSync, etc.) that come with every Palm device will be compiled for the Dragonball processor on a Palm OS 5 device? Or that...
    • Any application compiled for Palm OS 5 must still compiled for the Dragonball processor, and is run in emulation? I.e., that you cannot compile an application to ARM code if it's going to run under Palm OS 5?


    Thanks...
    Jeff Meyer

    "And he died like he lived: with his mouth wide open."
  5. #45  
    Originally posted by ****-richardson
    dkessler, forgive me if this sounds harsh, but I am all for the 'constraints on PalmOS developers.' Your (collectively, of course) code is going to bloat all to hell once those constraints have been removed, crippling any advantage the extra processing power and RAM would give. I, as an end user, am happy at the hoops you (collectively, again) have had to jump through, as it has made your apps as snappy as those being run on the PPC platform with triple the MHz.
    Ah, but keep in mind that many of those "hoops" actually cause a significant loss of performance. For example, on other platforms if I need a large chunk of memory to perform some data manipulation (let's say transforming a bitmap), I make one OS call to allocate it and then I have full read/write access to it. On Palm OS to do the same thing I'm supposed to create a database, allocate a new record (or resource), lock the record, then use a special OS function every time I write to the memory (since it's write protected by the hardware). Imagine how fast (and small) an already fast PalmOS app would be if it didn't have to go through all that

    I understand where you're coming from (the attitude that there's more that can be done with more horsepower), but I see it as an unnecessary price increase that will yeild little or no discernable advantage over what I am doing now.
    That may very well be true. The usage patterns for PDAs are quite varried. Some folks want them to be mini-laptops, others buy a PalmOS device and never even see the need for any third-party apps. I don't suggest that the benefits of a more powerful hardware platform can be realized by all users. But for some percentage of users, those potential benefits can offer significant rewards and should not be dismissed.
    <ul><li>Dave Kessler<br>President - Kopsis, Inc.</li></ul>
  6. #46  
    Originally posted by bookrats
    Or that...[*]Any application compiled for Palm OS 5 must still compiled for the Dragonball processor, and is run in emulation? I.e., that you cannot compile an application to ARM code if it's going to run under Palm OS 5?[/list]

    Thanks...
    My understanding (see disclaimer below) is that the release of PalmOS 5.0 will not include tools (compiler, linker, etc.) to produce a native ARM binary application. Developers simply get a new SDK for the additional APIs (high-res, security, multi-media, etc.) and continue to build Dragonball binaries that are run by the emulator built into PalmOS 5. I've been told that there is a way to drop out of emulation and execute native ARM assembly language, but the bulk of the application (at least those portions that interact with the PalmOS) must run in emulation.

    Disclaimer

    I'm not actively working on any PalmOS 5 development so don't take my word as gospel I haven't followed things on that front very closely and it's entirely possible that I'm totally wrong on this. I'm just reporting the last information that I heard.
    <ul><li>Dave Kessler<br>President - Kopsis, Inc.</li></ul>
  7.    #47  
    Originally posted by dkessler


    Ah, but keep in mind that many of those "hoops" actually cause a significant loss of performance. For example, on other platforms if I need a large chunk of memory to perform some data manipulation (let's say transforming a bitmap), I make one OS call to allocate it and then I have full read/write access to it. On Palm OS to do the same thing I'm supposed to create a database, allocate a new record (or resource), lock the record, then use a special OS function every time I write to the memory (since it's write protected by the hardware). Imagine how fast (and small) an already fast PalmOS app would be if it didn't have to go through all that
    Slower? probably
    a pain? definately
    But it does make software force to use a system that prevents them of memory that is allready used by something else and it prevents memory leakage...

    I'm not saying you don't know how to prevent that yourself, but the begining/less gifted programmer is forced to program in a clean way...
    If all programmers would be perfect we would not need it, but programmers are still human (even if they don't think so themselves ;D )
    <IMG WIDTH="200" HEIGHT="50" SRC=http://www.visorcentral.com/images/visorcentral.gif> (ex)VisorCentral Discussion Moderator
    Do files get embarrassed when they get unzipped?
  8.    #48  
    First saw the NR70V in real life at the local sony store... it just came in today and I happened to walk past it...

    Looks real nice in real can't wait for mine to arrive...
    It was smaller than I thought it would be..
    <IMG WIDTH="200" HEIGHT="50" SRC=http://www.visorcentral.com/images/visorcentral.gif> (ex)VisorCentral Discussion Moderator
    Do files get embarrassed when they get unzipped?
  9. #49  
    Originally posted by ToolkiT
    But it does make software force to use a system that prevents them of memory that is allready used by something else...
    Yes, but with modern hardware (processors that have a memory management unit) there are far more efficient and less intrusive ways to accomplish exactly the same thing.

    and it prevents memory leakage...
    Nope. It's still very possible to get memory leaks in a PalmOS app. I know from experience
    <ul><li>Dave Kessler<br>President - Kopsis, Inc.</li></ul>
  10. #50  
    Originally posted by dkessler


    My understanding (see disclaimer below) is that the release of PalmOS 5.0 will not include tools (compiler, linker, etc.) to produce a native ARM binary application. Developers simply get a new SDK for the additional APIs (high-res, security, multi-media, etc.) and continue to build Dragonball binaries that are run by the emulator built into PalmOS 5. I've been told that there is a way to drop out of emulation and execute native ARM assembly language, but the bulk of the application (at least those portions that interact with the PalmOS) must run in emulation.

    Disclaimer

    I'm not actively working on any PalmOS 5 development so don't take my word as gospel I haven't followed things on that front very closely and it's entirely possible that I'm totally wrong on this. I'm just reporting the last information that I heard.
    Actually, Dave, I think you're spot-on. I've been confused about this for some time, and your reply not only provided me with a concise explanation, but it spurred me to go out and do some research. Also, C.E. Steuart Dewar of Pimlico (Datebk3,4,5) verifies that's what he has understood -- and I know he's been compiling Datebk5 for Palm OS 5 specifically.

    Palm sums up the main pointshere, and they echo what you said. You can compile code that you need to run very fast in ARM format (if you can find the tools to do so -- see below), but the whole app can't be ARM -- the PACE emulation system has to be involved somewhere. And there's little support from the OS for the code.

    Apparently Metrowerks indicated that CodeWarrior would be coming out with some ARM support in future versions (there was a talk at PalmSource 2002 about this, apparently, but I have no details aobut it); but I don't know if that means support for a completely ARM application (which would be a lot of work without support from the OS 5 API) or support for letting your app execute code that requires fast code in ARM. I suspect the latter.

    Thanks for the initial reply -- the lightbulb went on after your explanation.
    Jeff Meyer

    "And he died like he lived: with his mouth wide open."
  11.    #51  
    Originally posted by dkessler
    Yes, but with modern hardware (processors that have a memory management unit) there are far more efficient and less intrusive ways to accomplish exactly the same thing.
    Wow didn't know that was available...

    Originally posted by dkessler
    Nope. It's still very possible to get memory leaks in a PalmOS app. I know from experience
    hehehe true very true, even the best programming language cannot prevent programmers to do something silly...
    My point was that this way it is less easy to do something silly...(but still possible of course )
    <IMG WIDTH="200" HEIGHT="50" SRC=http://www.visorcentral.com/images/visorcentral.gif> (ex)VisorCentral Discussion Moderator
    Do files get embarrassed when they get unzipped?
  12.    #52  
    How about build in apps, are they ARM specific or do they emulate too?
    <IMG WIDTH="200" HEIGHT="50" SRC=http://www.visorcentral.com/images/visorcentral.gif> (ex)VisorCentral Discussion Moderator
    Do files get embarrassed when they get unzipped?
  13. #53  
    Originally posted by ToolkiT
    How about build in apps, are they ARM specific or do they emulate too?
    I don't know, but the restrictions on ARM code appear to me to be "OS 5-wide", so to speak -- ALL apps for OS 5 would have to be written for 68K (though some of the speed-centric code could be rewritten for ARM).

    The question is, how much, and how much bang for their effort would they get? PalmSource would certainly have tools for compiling code to ARM (i.e., they're not having to wait for a Metrowerks CodeWarrior Palm version with ARM support.)
    Jeff Meyer

    "And he died like he lived: with his mouth wide open."
  14. #54  
    Originally posted by ToolkiT
    How about build in apps, are they ARM specific or do they emulate too?
    I'm sure they're not ARM specific, but I think this URL higher up on the page bookrats links to shows that it's not a hardware emulation. IOW, they're not emulating the dragonball or an older OS. What they're doing is more analogous to WINE on Linux than say...a PalmOS Emulator on a Zaurus or PocketPC. It intercepts the OS4 APIs and translates them into native ARM code.
    ‎"Is that suck and salvage the Kevin Costner method?" - Chris Matthews on Hardball, July 6, 2010. Wonder if he's talking about his oil device or his movie career...
  15. #55  
    Originally posted by bookrats
    [...] The question is, how much, and how much bang for their effort would they get? [...]
    I'll have to see if I can dig up the URLs, but the reports I've heard were that it was surprisingly speedy on many existing apps (the stuff I read mentioned which types of apps would run much faster).
    ‎"Is that suck and salvage the Kevin Costner method?" - Chris Matthews on Hardball, July 6, 2010. Wonder if he's talking about his oil device or his movie career...
  16. #56  
    Originally posted by Toby
    I'll have to see if I can dig up the URLs, but the reports I've heard were that it was surprisingly speedy on many existing apps (the stuff I read mentioned which types of apps would run much faster).
    Yeah -- it just didn't sound to me that it would be worth the effort to move chunks of your code to native ARM for the average application.

    And frankly, if PalmSource was going to concentrate on one thing for Palm OS 5, compatibility certainly strikes me as Job One. Good prioritization.
    Last edited by bookrats; 06/13/2002 at 04:39 PM.
    Jeff Meyer

    "And he died like he lived: with his mouth wide open."
  17. #57  
    Originally posted by Toby
    I'm sure they're not ARM specific, but I think this URL higher up on the page bookrats links to shows that it's not a hardware emulation. IOW, they're not emulating the dragonball or an older OS.
    Close. They are emulating the Dragonball CPU core (68000) hardware since the tools are still producing 68000 machine code. However, the services that the OS provides (memory management, graphics, etc.) are all implemented in native ARM machine code and designed specifically for the new hardware architecture. As a result, apps that spend a lot of time in the OS services might see some significant speed improvements. Apps that have little use for the OS (like games) or do a lot of computationally intensive stuff will not see much improvement despite the faster hardware.

    As for the built-in apps on OS 5 - they are running under emulation just like third-party apps. If PalmSource was far enough along with the OS (and development tools) to get reliable native versions of their own apps there'd be no reason not to let developers do the same.

    Additional explanation for those of you wondering what the heck all this "machine code" and "emulator" talk really means: Machine code the lowest level instructions that a CPU understands. It's basically a stream of numbers where each number (or sequence of numbers) instructs the CPU to perform a specific low level operation (eg. "read a byte from the location specified by the following number"). Every CPU family has its own unique set of instructions. Instructions for a 68000 (Dragonball) are meaningless to an ARM CPU. An "emulator" is a piece of software that reads codes meant for one type of CPU and translates them into equivalent codes for the local CPU. The whole process generally adds 400% overhead or more depending on the complexity of the translation but if the local CPU runs fast enough, it can offset the inefficiency of the whole process.
    <ul><li>Dave Kessler<br>President - Kopsis, Inc.</li></ul>
  18. #58  
    Originally posted by dkessler
    Close. They are emulating the Dragonball CPU core (68000) hardware since the tools are still producing 68000 machine code. [...]
    So, you're saying that Palm's lying, basically. Although, it doesn't make much sense why they would. Out of curiosity, if it was producing 68000 machine code (which I'd assume would be similar to x86 assembler type code in decipherability), what would it look like if opened in a standard text editor? Also, wouldn't it make more sense for the code that's accessing the ARM level directly to be faster than the emulated level (since it doesn't have to emulate the hardware you say it does)?


    Edit: added questions
    Last edited by Toby; 06/13/2002 at 05:01 PM.
    ‎"Is that suck and salvage the Kevin Costner method?" - Chris Matthews on Hardball, July 6, 2010. Wonder if he's talking about his oil device or his movie career...
  19. #59  
    Originally posted by Toby
    So, you're saying that Palm's lying, basically.
    Whoa, whoa. I think it's just a semantic debate over the term "emulation", and how it's used in the field. (And in high-tech, there are usually numerous definitions. Fuzzy logic rules.)

    I don't know what the right answer is; I write code for Microsoft Windows. The only Microsoft emulation I encounter is their emulation of "quality".
    Jeff Meyer

    "And he died like he lived: with his mouth wide open."
  20. #60  
    Originally posted by bookrats
    Whoa, whoa. I think it's just a semantic debate over the term "emulation", and how it's used in the field. (And in high-tech, there are usually numerous definitions. Fuzzy logic rules.)
    Except that one can't simultaneously be not emulating a processor (or any other hardware), and yet be interpreting machine code that needs that processor. If I could write a program in assembler on the PC to talk directly to the x86 instructions, there isn't any way to port it to another platform without emulating that processer. I also probably wouldn't be able to read any plain English from the resulting compiled program. OTOH, if I can write to the Win32 API, anything that can sit there and intercept it can translate it to something else that can translate those APIs to another platform.
    I don't know what the right answer is; [...]
    That's what I'm trying to find out. Palm's statements can only be reconciled if when they say "it interprets the 68k instructions itself, and handles 68k trap instructions (used by applications to call OS APIs) by making calls into the native Palm OS 5 system." they really mean the programs written for that previous OS platform which talk to the APIs and not 68k machine level instructions. That one little sentence (which on the surface might seem to support Dave's claim) is totally incongruous with "PACE does not emulate the 68k chip or other hardware, nor does it run the old OS." using any reasonable definition of 'emulate' that I can think of.
    ‎"Is that suck and salvage the Kevin Costner method?" - Chris Matthews on Hardball, July 6, 2010. Wonder if he's talking about his oil device or his movie career...
Page 3 of 4 FirstFirst 1234 LastLast

Posting Permissions