> 
> OK, here's the scoop, as far as I can tell:
> 
> The SoftwareFPU documentation mentions that the 68LC040 chip bug is on
> Motorola's 68LC040 errata sheet, revision 4 and later, as bug E4. The most
> recent revision of the sheet on Motorola's site is the 68040 errata,
> revision 1. Either this is something weird with the numbering or the web
> site is way out of date.

As Dave mentioned, it's probably bug E4, on sheet rev. 1. The "this chip
mask fixes this bug" section seems to indicate "E4" is a traking name.

> The bug itself has nothing to do with RTE or returning from F-line
> exceptions. Sorry for the misinformation. Instead, pending CPU writes to
> memory are never completed when an F-line exception occurs. As mentioned
> before, this never affected the MacOS until SoftwareFPU came along, so it
> was not discovered until it was too late.
>
> As for the mention by Mason Loring Bliss that this bug was fixed in later
> versions of the chip, I'm not sure. I do know for a fact that the chip in
> my Performa 637CD *has* the bug, because SoftwareFPU never worked reliably
> on my system. Presumable Ken's LC 630 does too. =(
> 
> As mentioned before, the bug can be worked around by putting NOPs before
> every F-line instruction on the application level.

So basically, for NetBSD to EVER run on an 040LC, we have to either compile
the silly thing with soft-float (sp?) or stick NOP's in front of all of
the floating point instructions?

Gross.

Sounds like we might need two distributions. ?? The LC040 will need some
sort of fix, but I'd rather not add unneeded NOP's to my poor IIsi's
code (it already earned the name "pokey". :-)

Is there some way to tell which revision of chip one has?

How hard would it be to teach gcc to not get bitten by this bug? How much
can we grumble at Motorola for not having helped fix gcc by now. :-)

Take care,

Bill