I went through the process of 16 bit DOS programs with similar segmentation limits to the issues I run into on creating large programs on Palm OS. The reason my (DOS) applications don't port to 32 bit Windows is because the operating system is dramatically different, not because the Pentium is different from 8088, or because 16 bit segments aren't needed on 32 bit processors. It would have been possible to create 32 bit DOS, but nasty because of all the lowel level assumptions within the operating system created by the lack of a sufficiently abstract API set. Basically it's entirely the problem of the guys who write the compilers and the guys who create and maintain the OS's API set. The application coder SHOULDN'T have any idea of program segmentation and 32KB jump limits, etc. If this is all handled by the compiler (as it almost is using CodeWarrior) then when moving to a processor with true 32 bit addressing, all that should be required is a recompile and relink with the correct compiler settings. But if you are one of the souls writing code with "jump islands", explicit register allocations, etc., then moving to a different processor is going to be rough, because you'll have to rip out all the stuff that compiler should have been handling for you all along. And the big-endian, little-endian issue is only a problem if if really matters (within your code) which end is up. If so, encapsulate that code, don't replicate it. The big issue on the Palm OS in moving forward is to maintain compatibility in the OS API's. If they do that, then migrating existing applications forward will be relatively easy even to processors quite alien to the DragonBall. I think the biggest issue will be taking most current applications to a different screen profile. The 160x160 is specifically coded into most software. If Palm OS's primary plaform suddenly had a 320x480 screen (not a bad idea!), we'd all find our code running in the top left corner (or what ever the default would be for the current apps) Roger Stringer (Glad to programming in C++ in CodeWarrier on Windows!) ---------------------------------------------------------------------- >Subject: Re: End Of Dragonball? Palm Shakeup? >From: [EMAIL PROTECTED] (Michael Sokolov) >Date: Tue, 25 Apr 00 12:13:20 CDT >Michael S. Davis <[EMAIL PROTECTED]> wrote: >> I wonder how this will effect the development platforms. Specifically >> will this new processor require new GCC and prc-tools setup to be able >> to develop for the new processor? >I doubt that you will even have PRCs on any other processor. The very design of >the PalmOS memory architecture is practically defined by the properties, >peculiarities, and limitations of the 68000/Dragonball. Why does PalmOS have >the notion of memory "cards"? AFAIK because the Dragonball does. Why is >everything in PalmOS (chunks, records, resources, you name it) designed around >the 64 KB limit? Probably because of the -32 KB to +32 KB locality of reference >limit in the 68000. Where does this whole notion of segments come from? From >there. >With any other processor the entire PalmOS memory architecture, as well as the >database architecture and whatever will replace the PRCs will have to be >redesigned from scratch. And so of course will all development tools. And so >will all PalmOS software that is even a tiny little bit hacky. >-- >Michael Sokolov Harhan Engineering Laboratory >- -- For information on using the Palm Developer Forums, or to unsubscribe, please see http://www.palm.com/devzone/mailinglists.html
