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 4 of 4 FirstFirst 1234
Results 61 to 68 of 68
  1. #61  
    Originally posted by Toby
    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.
    The PACE document you referenced was clearly "refined" by marketing people trying to defuse potential public aversion to emulation technology. When it says that PACE does not emulate the 68k chip it is technically accurate because the MC68328 Dragonball chip contains a lot more than just the 68000 CPU core. Dragonball also includes LCD control, memory control, interrupt control, real-time clock, etc. PACE is only emulating the CPU core so technically it is not emulating the whole chip. For example, if an app talks directly to the display controller (for example OS 3.1 apps with 4-bit grayscale support), it won't work under PACE.

    But the fact remains that PACE is emulating the "CPU" part of the Dragonball chip (a.k.a. "interprets the 68k instructions itself") for application code and redirecting OS calls to native ARM code just as I described.

    As for the question of what you would see if you viewed 68k machine code in a text editor - you'd see what looks like random garbage (with an occasional readable text string here and there). The same for x86 machine code. It's easy to confuse machine code with assembly language. Assembly language is a human readable representation of machine code. For example (we're going way off-topic here but who cares ) the following is a 68k assembly language instruction:

    addi.d #8, r0 ; add 8 to the contents of register 0

    In 68k machine code that's represented by the following sequence of bytes (shown in hexadecimal representation):

    06 C8 00 00 00 08

    It's those byte sequences that the current Palm development tools produce for application code. But that same sequence of bytes means something totally different on an ARM or x86 CPU (the x86 doesn't even have an "r0" register) so in order to execute on that platform it has to be interpreted by a software application that is emulating the 68k processor. That's exactly what PACE is doing.
    <ul><li>Dave Kessler<br>President - Kopsis, Inc.</li></ul>
  2. #62  
    Originally posted by dkessler
    The PACE document you referenced was clearly "refined" by marketing people trying to defuse potential public aversion to emulation technology.
    That still doesn't answer the question of how the supposedly emulated code would run faster than other code. It should be the opposite, n'est ce pas?
    When it says that PACE does not emulate the 68k chip it is technically accurate because the MC68328 Dragonball chip contains a lot more than just the 68000 CPU core.
    Except that it doesn't say that it doesn't emulate the dragonball chip. Again, it says: "PACE does not emulate the 68k chip or other hardware, nor does it run the old OS." Even emulating just the core would certainly seem to fall under 'other hardware'.
    [...] PACE is only emulating the CPU core
    Do you happen to have documentation of that (or a link to such)?
    so technically it is not emulating the whole chip. For example, if an app talks directly to the display controller (for example OS 3.1 apps with 4-bit grayscale support), it won't work under PACE.
    The way Palm phrases it on that page, if it talks directly to _anything_ other than the PalmOS API, it won't work under PACE.
    But the fact remains that PACE is emulating the "CPU" part of the Dragonball chip (a.k.a. "interprets the 68k instructions itself") for application code and redirecting OS calls to native ARM code just as I described.
    Again, if that's accurate, then Palm is lying.
    As for the question of what you would see if you viewed 68k machine code in a text editor - you'd see what looks like random garbage (with an occasional readable text string here and there).
    What sort of readable text strings?
    The same for x86 machine code. It's easy to confuse machine code with assembly language. Assembly language is a human readable representation of machine code.
    Sorry, but I was a bit sloppy with that reference.
    For example (we're going way off-topic here but who cares ) the following is a 68k assembly language instruction:

    addi.d #8, r0 ; add 8 to the contents of register 0

    In 68k machine code that's represented by the following sequence of bytes (shown in hexadecimal representation):

    06 C8 00 00 00 08

    It's those byte sequences that the current Palm development tools produce for application code.
    For _any_ application code, or only application code trying to talk to the hardware?
    But that same sequence of bytes means something totally different on an ARM or x86 CPU (the x86 doesn't even have an "r0" register) so in order to execute on that platform it has to be interpreted by a software application that is emulating the 68k processor. That's exactly what PACE is doing.
    Again, if that's accurate, then Palm is lying.
    ‎"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...
  3. #63  
    Nevermind, the more I read their documentation, the more I think _they_ aren't sure what the hell PACE is. The only way I can see that their statements and yours are able to reconcile in any way is by taking your 'core' wordage in the context of 'instruction set' basically meaning the software which chip manufacturers hardcode into their chip design. It seems a weasly way around saying they don't emulate 'other hardware' though.

    As an aside on Palm programs in general, are some parts of PRCs compiled on the fly into 68k machine language? Otherwise, why would their be human-readable API references in them?
    ‎"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...
  4. #64  
    Incidentally, it appears that PocketPC may be going through similar troubles in its XScale transition...http://www.silicon.com/bin/bladerunn...=REQINT1=53873
    ‎"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...
  5. #65  
    Originally posted by Toby
    That still doesn't answer the question of how the supposedly emulated code would run faster than other code. It should be the opposite, n'est ce pas?
    The application (not executable code in general but the overall application) running in emulation can run faster because most PalmOS applications spend a large percentage of their execution time in functions that are in the OS itself. Since the OS functions are native ARM code (no emulation required), they run much faster than they do in OS 4.x on a Dragonball. The application's code itself takes a lot more clock cycles to execute because of the emulation. But since the clock cycles are much shorter (faster CPU) and the OS functions are faster, the overall performance can be similar to or better than current Palm devices.
    <ul><li>Dave Kessler<br>President - Kopsis, Inc.</li></ul>
  6. #66  
    Originally posted by dkessler
    The application (not executable code in general but the overall application) running in emulation can run faster because most PalmOS applications spend a large percentage of their execution time in functions that are in the OS itself.
    I thought that was the whole point of OS5, though. That it was going to run the same functions as the existing OS (with a few additions), just on ARM instead of 68k.
    Since the OS functions are native ARM code (no emulation required),
    OK, what do you mean by 'OS function' here? The PalmOS APIs? I think that's where some signals might be getting crossed.
    ‎"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...
  7. #67  
    Originally posted by Toby
    It seems a weasly way around saying they don't emulate 'other hardware' though.
    Bingo! Welcome to the wonderful world of the marketing spin doctors The public is scared to death of "emulation" because they know from experience that full hardware emulation slows things down bad! Palm isn't doing full hardware emulation. Their approach is pretty clever and should work pretty well (if people keep reasonable expectations), but how does one explain the difference between "full hardware emulation" and "CPU core emulation with native trap execution" to the general public? It isn't easy And for marketing folks without an extensive engineering background it's even more difficult. The result is the PACE document that we've been discussing. Yes, it contains some semantic problems and contradictions, but in general the point it's trying to make (PACE emulation isn't like traditional full hardware emulation) is reasonably accurate.

    As an aside on Palm programs in general, are some parts of PRCs compiled on the fly into 68k machine language? Otherwise, why would their be human-readable API references in them?
    No. The human-readable parts aren't API references. They are the strings of text that the program displays to the user. For example if my program generates a message box that says "14 files deleted!", the text string "%d files deleted!" is likely to exist somewhere in the .prc file. Only in rare cases will you find a .prc file containing human-readable function names. If you do it's because it was built to contain debugging information. That information has nothing to do with the execution of the code, it's only for use by debugging tools. It can be stripped out (and usually is because it wastes a lot of space) without any effect on the program's execution.
    <ul><li>Dave Kessler<br>President - Kopsis, Inc.</li></ul>
  8. #68  
    Originally posted by dkessler
    [...] but how does one explain the difference between "full hardware emulation" and "CPU core emulation with native trap execution" to the general public? It isn't easy
    Sure, but this is information that I'd be surprised if the average Joe is going to go looking for. If you talk to your _developers_ at the same level as the general public, that's not a good sign, IMO.
    [...] Yes, it contains some semantic problems and contradictions, but in general the point it's trying to make (PACE emulation isn't like traditional full hardware emulation) is reasonably accurate.
    Well, unfortunately, I've never gotten around to digging into PalmOS programming, so my biggest hurdle is not knowing how many layers of abstraction they're using compared to the stuff I'm more familiar with (and although they have an easy to find graphic for OS5, I wasn't able to find one quickly for OS4 and previous).
    No. The human-readable parts aren't API references. [...]That information has nothing to do with the execution of the code, it's only for use by debugging tools. It can be stripped out (and usually is because it wastes a lot of space) without any effect on the program's execution.
    Ahh... The only one I had handy evidently had lots of debug info, then, because ISTR those hsCard... APIs when I was looking through the springboard development docs.
    ‎"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 4 of 4 FirstFirst 1234

Posting Permissions