Re: [buildd] Etch?
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
Reply to: