[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: [buildd] Etch?

Geert Uytterhoeven <geert@linux-m68k.org> 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


Reply to: