>On Thu, 7 May 1998 16:06:56 -0400,
>rbraun@cstone.net (Rolf Braun) wrote:
>
>> I know, about last year I was discussing the hardware bug on the list with
>> Ken and some others. The workaround in that case is -msoft-float.
>
>I'd be surprised if it helped.  But I've heard from someone it helped
>(someone in UK actually compiled the whole system with -msoft-float).
>Hmm...  Why?  Because NetBSD comes with libgcc2 routines necessary for
>-msoft-float, but they do use FPU instructions.  That means, even if
>you compiled your whole system with -msoft-float, some FPU
>instructions would still be used.

Is this -msoft-float distribution available anywhere, or it is too old?

>Ah...  Yes, *some* FPU instructions would still be used but FMOVEM
>would not be one of them.  That can help.
>
>Side note: I'm converting FPE to use double as the internal floating
>point number representation (in order to reuse libm source), instead
>of Sparc FPE internal format (112-bit significand).  But kernel won't
>compile without the soft-float routines mentioned above.  And they
>have to be absolutely free of FPU instruction.

Hmm. Wait a minute, if the kernel has to be absolutely free of FPU
instructions, then how can you compile it if even -msoft-float generates
FPU instructions?

>> They're consistent in that they occur at relatively the same frequencies in
>> the same binaries. They don't always occur in the same place.
>
>That's puzzling me, too.  I'm starting to suspect that there may be a
>problem in someplace other than FPE (a la the stack frame size bug
>found and fixed by Kelly Campbell).
>
>> If the bug was indeed fixed by Moto before Apple canned the 040, then I'd
>> expect that it is fixed in the 630 series, since that was one of the last
>> 040 models produced.
>
>However, I've seen an LC630 and an LC575 equipped with XC68LC040RC
>(the XC prefix denotes engineering samples)...  The last 68k Macs
>equipped with the earliest LC040 chips.
>
>Although, IIRC, XC68LC040's don't have the F-line trap bug according
>to Steve Allen.  The bug was made into a later mask revision when
>Motorola shrank the die size.

Oh? Hmm, maybe I'll open this thing up and see if it's an XC chip. Then I
know I don't have the bug. :))

>> >I doubt that vi and dt use the FPU/FPE at all.  That would be why
>> >they're more stable than ls or ps (which do divisions, at least).
>>
>> I seem to remember that printf() uses FPU somehow...
>
>Yes, it does.  Even if you call printf() with no floating point
>arguments, it does FMOVEM which seems to be causing the `random'
>segfaults.  Vi and dt may have calls to printf(), but I can imagine
>they don't usually make the calls; Both programs are fairly screen
>oriented.

Hmm, maybe getting some float variables out of printf() would help?

>Anyway, I got a loaner LC575, thanks to Kazunori Miura and Kobunsha,
>and I'm actively working to fix FPE.

Cool. Thanks. :)

--
- Rolf Braun - rbraun@cstone.net - http://www.cstone.net/~rbraun/
- Sassy Software: cool software for your Macintosh or Apple IIgs
- Rolf's HTML & Stuff: creative web design for less

- Anyone attempting to post messages or send e-mail using my address
- without my permission will be held legally liable for forgery, and
- may be subject to legal action and severe legal penalties.