> > *hose* ? Doesn't this mean 'drag to a grinding halt'? Really?
> 
> It's one extra instruction per LDM. It doesn't affect the condition codes
> (it's still one extra instruction in the execution path whether the LDM
> executes)
> I think code is roughly 1% larger and probably about 1% slower

Yes, this is in the correct ball-park.  I've just grep-ed some assembler 
files I have lying around and ldm ...pc} makes up about 1.2% of the 
instruction mix;  typically half of those will require a pad instruction 
before-hand.  However, this still inserts far more padding than desirable, 
since only one in 500 of those return instructions would have ended up on 
a page boundary (1024 instructions per page and in this case we know that 
half of them were already on an even alignment and won't need adjusting).

> 
> Which is enough to make me unhappy, hence I agree with
> 
> > > > > Summary: I still don't think fixing the compiler is the correct way to 
> > > > > address this bug.
> 
> > But has Nicholas got the fix right? I'm sure most ordinary 200MHz Rev K users
> > would treat this as a major leap forward; after all, Linux manages to fix the 'F00F'
> > bug without asking everyone to upgrade their x86's to non-buggy ones...
> 
> my kernel hasn't crashed (but then again it didn't before) so I've not made
> that worse.

Your kernel should *never* crash because of this bug.  The executable may 
not function correctly, but if your kernel is crashing there is a bug in 
your kernel.  End of statement.

> egcs bootstraps (almost - stage 2 and stage 3 are choosing different registers
> but that's a separate issue) whereas before stage2 genrecog would segv
> perl now passes io/pipe.t and op/closure.t
> 

Hmm, (getting gcc technical) I've seen this happen if the floating point 
format changes -- is one version using soft-float and another emulated 
floating point?

> It works. It's not elegant, but it works so far
> 

Don't forget you also need to fix up pointer-to-function calling, which 
uses
the sequence 
	mov	lr, pc
	ldr	pc, [reg, ...]
For this it is important not to split the two instructions, so you will 
need to align, do a padding nop and then emit the sequence.

Finally, I think there is a similar problem with case dispatch tables 
(which use ldrls pc, [pc, reg, lsr #2]).  Fixing these up is even harder, 
so it would probably be better to just make them work in the same way as 
the PIC dispatch tables (which use "addls pc, pc, reg, lsr #2" with a 
table of branch instructions).

> > Does your 'this isnt the right approach' thing mean that the patch for egcs won't
> > be put into NetBSD/arm32? Cos if so, I'm off to the Linux camp right now... :-)
> 
> Why not just build your own gcc with it, and while you wait hunt down the
> DEC errata sheet and then work out how to rejig the kernel to set the MMU in
> such a way to work round the bug (assuming I understood Richard's reply
> correctly)
> 
> Where is the DEC errata sheet? (Have I committed a FAQ?)
> 

Probably.  Here's one source:
http://www.research.digital.com:80/SRC/iag/info/dnaext/docs/sa110-errata.pd
f

Richard.