BTW, Ben, just to respond to your MHz question:
For me, it's about graphics, which means it's about memory and graphics bus bandwidth.
My only processor MHz requirement is that the
processor is fast enough to at least keep up with moving the memory around if not do
some simple live filtering on it.
As the Palm graphics increase, it is getting SLOW:
For example, the old standard 2-bit palm had a 6K screen! The Visor Prism needs
nearly 10 times the bandwidth, yet has only double
the procesor speed. Assuming Palm takes steps in the new future to go to 32-bit color
and 320 resolution, that's now EIGHT times the
bandwidth requirement of the Prism. And I have to crank out 20 frames a second. :)
DIAMOND JEFF wrote:
> Thanks so much, Ben!
>
> I really appreciate the info. I'm really suprised Palm would make such a leap.
>
> I can't think of any way Palm could emulate Big Endian mode successfully, though:
>
> Palm programs mostly do struct copy stuff like this:
>
> MyStruct shadow, *pRecord;
>
> pRecord = (MyStruct*) MemHandleLock(DmGetRecord(pDB, 1)));
> shadow = *pRecord;
> DmWrite(pRecord, sizeof(MyStruct));
>
> To the PalmOS, all structure copies are just 1d byte copies -> only the applications
>knows what things need to be swapped, so the
> values in shadow will be garbage.
>
> And does this imply changes to the PDB format, which has some big endian unions?
> Man -> Palm Source is IMPORTANT - anyone know if there are summaries of such things?
>
> Thanks!
> - Jeff
>
> Ben Combee wrote:
>
> > "DIAMOND JEFF" <[EMAIL PROTECTED]> wrote in message
> > news:37921@palm-dev-forum...
> > >
> > > I'm sure Palm has already worked all this out, but in case any of the
> > > results are surprising, I thought I'd ask so I can begin preparations.
> > >
> > > My impression of the standard ARM core (and maybe Palm has found a
> > > variant) is that:
> > >
> > > (1) Big Endian mode only has second class support, i.e., swap on
> > > load/store
> > > (2) 32-bit word accesses must occur on 32-bit aligned boundaries.
> > >
> > > Obviously, if either of these points remains, the implications are
> > > staggering: all applications need to be recompiled, all pre-existing
> > > databases need to be migrated, and all programs must be debugged for
> > > every instance of the logical equivalent of a union.
> >
> > They both will be in the ARM Palm -- At PalmSource 2000, we were told that
> >
> > 1) OS 5 will do some structure conversion returning proxy structures to 68K
> > code, but in most cases, you will be required to go through the API
> > functions to read and write to system structures.
> >
> > 2) An ARM Palm will be little endian.
> >
> > 3) 32-bit alignment will also be an issue -- the system structs will be
> > rearranged to not have any unnatural boundaries. Also, 68K code running
> > emulated wouldn't have alignment issues, since those can be fixed at
> > emulation time. New code that you build for both 68K and ARM should respect
> > 32-bit alignment.
> >
> > > Also, while this would have a slight hit on cost, I certainly hope Palm
> > > is going for a 32-bit bus to the data and instruction caches and as wide
> > > a bus as possible from cache to ram. The whole key to getting
> > > performance at low power is low frequency / high bus width - and you're
> > > gonna need as much memory bandwidth as possible to feed those high MHz
> > > ARMs. :) Of course, this is assuming the primary goal of the migration
> > > effort is for future performance and not merely for better CPU supplies.
> >
> > Why do you need high MHz ARMs? I've seen plenty of ARM applications where
> > the clock speed was similar to the current DB clock speed. I once helped
> > design an ARM system which usually was running at 32KHz (yes, kilohertz). I
> > think a two primary goals of the ARM move is compatability with cell phone
> > cores which are predominantly ARM and allowing multiple suppliers of CPU
> > chips, removing the Motorola monopoly.
> >
> > --
> > Ben Combee
> > Veriprise Wireless <http://www.veriprise.com>
> >
> > --
> > For information on using the Palm Developer Forums, or to unsubscribe, please see
>http://www.palmos.com/dev/tech/support/forums/
>
> --
> For information on using the Palm Developer Forums, or to unsubscribe, please see
>http://www.palmos.com/dev/tech/support/forums/
--
For information on using the Palm Developer Forums, or to unsubscribe, please see
http://www.palmos.com/dev/tech/support/forums/
