Geert Uytterhoeven <[EMAIL PROTECTED]> writes:
> 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
>> problem.
>
> But I guess this is a problem if you do
>
> movem.l d0-d1,-(a7)
> fmovem fp0-fp1,-(a7)
> movem.l d2-d3,-(a7)
>
> 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
> in?
A nice bus error (or similar exception). Some m68k also had that
behaviour, either 68000 or 68010. Very bad if you do it.
It is probably save to consider any push/pop of bytes to/from the
stack a bug in the code and ignore the issue. Make gcc generate a
equivalent move.w construct that behaves the same on both archs to
avoid C code from having it.
> Gr{oetje,eeting}s,
>
> Geert
MfG
Goswin
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
