>Unless you compile everything with -msoft-float, it would still
>execute *some* FP instructions which would then cause the same "random
>segfaults".  I personally wouldn't hold my breath until someone built
>a complete -msoft-float distribution...
>

That's exactly what I was referring to... =) It would be possible, though,
I gather.

>
>P.S. I've got around to take a closer look at my LC630 (which has an
>LC040) running a custom kernel (which would drop at the debugger
>whenever the processor attempted to execute an FP instruction).  I
>think the problem is a little more complicated than I and a few others
>thought it would be, but I'm expecting to collect more information on
>the problem in this couple of weeks.  Stay tuned.

What I'm really afraid of here is a known bug in the 68LC040 chip.
Apparently, the author of SoftwareFPU ran into this, and as a result,
SoftwareFPU doesn't work on 68LC040s. It's a known bug listed on Motorola's
errata sheet. As far as I know, there is no workaround.

The nature of the bug is that the 68LC040 sometimes doesn't set the program
counter correctly when returning from an F-line exception. Normally, F-line
exceptions never return, so this isn't a problem. I don't know if the
NetBSD FPU emulation works the same way as SoftwareFPU; if it doesn't, this
might not apply. One possible solution would be to put a NOP before every
F-line instruction; apparently that works, at a cost of speed for
FPU-enabled computers.

Again, I don't at all know if this has anything to do with NetBSD's FPU
emulation; I'm just passing it on. If this is the case, -msoft-float is the
only way to go.

- Rolf Braun ... rbraun@geocities.com ... TidalWave on IRC
- Sassy Software: cool stuff for Macintosh & Apple II
- http://www.geocities.com/SiliconValley/Heights/3110/
- Help for Mac UNIX questions ... #MacUNIX on EFnet IRC