On Fri, Aug 04, 2006 at 02:37:03PM +0200, Geert Uytterhoeven wrote: > 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.
Yes. I'm not saying it's /no/ problem, I'm only saying it can be dealt with in a fairly reasonable manner, and thus isn't _much_ of a problem. The answer to your above example would be "Don't do that, then". Save the fpu registers first, and the data registers after that. Avoid doing it like above if at all possible; if you really really _need_ to do it this way due to external factors, copy the address in a7 somewhere else before doing the fmovem so that you don't need to do a7-relative addressing but can do something else (another address register, perhaps, or memory-indirect if all else fails). Granted, that isn't optimal, but it's a solution. You need to be careful in using FMOVEM; if you are, everything is fine. > > * 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? Interrupts happen in kernel mode, not in user mode (unless I missed something? I'm fairly new to all this). ColdFire is way different from 68k in supervisor mode to the point that it doesn't even remotely seem possible to extend the hybrid mode to the supervisor programming model, so I'm not even trying. Shipping different kernels for classic 68k and ColdFire isn't exactly hard at all, anyway. Moreover, isn't one of the first thing the kernel will do on a context switch (which an interrupt is, right?) to save the registers off to some place and load register state for some other process? So then the original process that got interrupted can align its stack pointer later (when the context is switched back), and the process or interrupt handler which we're loading now will presumably have an aligned stack pointer already. No? That being said, if interrupts can indeed interfere in that way, then Stuff Breaks. This difference certainly is /much/ more of a problem than the above one. Especially since, if you indeed do push one byte on the stack, you have to verify whether the stack pointer is aligned, and align it if it hasn't, which takes a fair amount of opcodes and thus processing time. This sucker should be avoided at all costs; I'd think it'd be better to just push a word on the stack instead of a byte, and only use the first byte if you only need a byte anyway. In that scenario, both processors act exactly the same way; and I don't think that pushing a word on the stack (as opposed to pushing a byte) will take a hell of a lot more processing time. -- Fun will now commence -- Seven Of Nine, "Ashes to Ashes", stardate 53679.4 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
