Re: [buildd] Etch?
On Fri, 4 Aug 2006, Wouter Verhelst wrote:
> Indeed. However, I do not feel that the impact will be unbearably large.
> So far, I have found only two cases where the documentation documents
> different behaviour for a given opcode on ColdFire vs 68k:
> * Moving data from FPU registers to memory with FMOVEM will overwrite 10
> bytes per register on classic 68k, but only 8 per register on
> ColdFire, due to the differences in FPU register length. This is a
> problem if you try to access the data in memory after pulling it out
> with FMOVEM, but it is not if you use it to store the state of your
> registers at the beginning of a function, so that you can restore the
> state at the end of the same. I presume that that's what FMOVEM was
> intended for anyway, so I do not consider this to be much of a
But I guess this is a problem if you do
and want to access the saved d0 and d1 later, relative to a7, as they will be
at different offsets.
> * Using address register indirect with predecrement or postincrement mode
> on the stack pointer (A7) in byte context will increment resp.
> decrement the stack pointer with 2 bytes on classic 68k, but with 1
> byte on the ColdFire. Both still need to be aligned on two bytes,
> however. As a result, this addressing mode should be avoided; but I do
> not think that it is used very often.
Hmm... So what happens if you push 1 byte on the stack, and an interrupt comes
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- firstname.lastname@example.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds