> *hose* ? Doesn't this mean 'drag to a grinding halt'? Really?

Well, perhaps hose is a bit harsh, but it does impact performance (in 
effect for everybody if you want to share binaries across machines), and 
it affects performance far more than the binary patch approach (which 
typically has to patch up less than half a dozen instructions in a 
normal-sized program).

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

It may work for Linux (I don't use it so I can't say for certain): it 
won't work for NetBSD.  As I said in a previous message, NetBSD is using 
a.out object format where the .text section in the object files is only 
aligned to a 4-byte boundary.  It is therefore impossible to align the 
problem instructions to an 8-byte boundary.

> bug without asking everyone to upgrade their x86's to non-buggy ones...
> > > > Richard (gcc/arm maintainer).
> > > 
> 
> 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... :-)

Well, I don't have final say over goes into the NetBSD copy of egcs; but 
I'm going to need a lot more convincing before this gets put into the egcs 
master sources at egcs.cygnus.com.


Richard.