On Tue, Aug 08, 2000 at 02:26:25PM +0200, Florent Pillet wrote:
> on 8/08/00 9:25, Tom Zerucha at [EMAIL PROTECTED] wrote:
>
> > Or Movem.l which moves lotsa bytes for 4 bytes of instructions.
>
> Thanks to all for your answers. Yes I have the 68k cycles chart (back to the
> Atari ST, I was already doing that kind of optimization) but I did not catch
> on the fact that there is no built-in instruction cache in the dragonball.
> The original 68k cache was very small but at least there was one.
Not true. The Dragonball has the ORIGINAL 68k core. The 68010 (which
wasn't in the Atari STs ever, and the original 520/1040 and the Megas
had 8 Mhz chips - but there was a 16mhz upgrade).
The original 68k has NO cache. The 68010 has a "loop mode" which
means most instructions (add, cmp, move) when followed by a DBcc
instruction will not cause an interveining opcode fetch until the loop
is complete (or an interrupt happens), so it can copy, set, or compare
memory at full bandwidth (If the archives go back long enough, you
will find a diatribe I wrote basically telling Palm to use the 68010
core for this reason).
Currently Motorola has many cores - the 68EC020 (EC=embeddec core -
some things are stripped such as the barrel shifter) has advanced
addressing modes. CPU32 has a pipeline and will do loopmodes like the
010, but is more efficient since it can fetch while doing other
things.
> About misaligned copies, yes the 68k core will generate an exception but
> there is an old trick for that kind of copies: it's called MOVEP. Was
> originally designed for talking to hardware registers of on-board
> processors, but can be used for graphics copies as well.
It does every OTHER byte so can interleave - not quite the same.
--
For information on using the Palm Developer Forums, or to unsubscribe, please see
http://www.palmos.com/dev/tech/support/forums/
