On Fri, 8 May 1998 10:57:20 -0400,
rbraun@cstone.net (Rolf Braun) wrote:
> 
> Is this -msoft-float distribution available anywhere, or it is too old?

Not that I'm aware of.  That someone compiled the system for himself,
apparently.

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

Gcc with -msoft-float does *not* generate FPU instructions but
generates calls to subroutines (which usually reside in libgcc{,2}.a).
Those subroutines are supposed to take care of soft-float issues.
NetBSD/m68k comes with a set of such subroutines that simply do the
job by FPU instructions.  For instance, adding two doubles would just
do it by an FADD instruction.  I need a replacement set of the libgcc
soft-float subroutines that do floating point arithmetic by integer
arithmetic.

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

Well, yes, maybe (actually, not printf() but vfprintf() to which
printf() is a wrapper).

Ken