> 2) There are at least two different ARM chips -- Motorola's Dragonball > MX1 with the ARM920T core, and Texas Instrument's OMAP processor, with a > core unbeknownst to me (ARM925T?). Again, Palm says it will stick with TI > for most of its new devices -- yet, Motorola is going to keep chugging away > with new versions of Codewarrior for ARM. Does this schism mean that PalmOS > licensees might combine PalmOS + Dragonball MX1, while Palm devices will > combine PalmOS + TI's OMAP architecture? Will Codewarrior for ARM be > able to compile for both the Motorla and TI scenarios, or will a new IDE need > to be introduced (!!)?
Our embedded CodeWarrior for ARM product supports the Dragonball MX1, Intel's XScale, and TI OMAP chips as well as any chips that support the ARM instruction set. For the most part, all ARM core chips understand the same instruction set. User programs won't need to be recompiled for an OMAP or a Dragonball or an XScale. The only parts of the system that might be customized for the different chips would be the OS code and libraries provided by the licensees. Its a similar situation to the current 68K scenario: Palm OS runs on the original Dragonball, the EZ, the VZ, and now the SZ. All of these chips have different physical register sets and require their own tweaks to the OS. However, user programs don't need to be concerned what chip they run on. On the new NR CLIEs, Sony is providing a special shared library for JPEG decoding that takes advantage of the SZ's special hardware. We haven't announced exactly how we'll support ARM development, but unless you're a Palm OS licensee or you want to make OS-level code, you shouldn't have to worry about which of the many ARM-core CPUs you will be running upon. -- Ben Combee <[EMAIL PROTECTED]> CodeWarrior for Palm OS technical lead Get help at http://palmoswerks.com/ -- For information on using the Palm Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/support/forums/
