In the last mail Steve Dicks said:

> On Mon, 29 Mar 1999 19:49:13 +0100, rearnsha@arm.com said:
> 
> >
> > .align 3 (by which I assume you mean align to a 2^3 boundary -- different 
> > arm assemblers unfortunately put different interpretations on this 
> > *groan*) has no meaning unless the section that it is placed in is also 

gas puts different meanings on it according to what platform you're on
(according to the man page)

> > guaranteed to be this aligned.  I can't speak for the ELF format off the 
> > top of my head but this is not the case for a.out which only aligns 
> > sections to a 4-byte boundary.  It also fills the instruction stream with 
> > arbitrary padding that aren't guaranteed to be nop instructions (though I 
> > think that they will normally have that effect with gas -- 0 == andeq r0, 
> > r0, r0).   Don't forget that gcc emits conditional ldm...{...,pc} as well. 
> >  Packing these out can really hose your performance.
> >
> *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

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.
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

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

> 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?)

Nick