On Thu, 22 Feb 2001, Richard Earnshaw wrote:

> > On Wed, 21 Feb 2001, Richard Earnshaw wrote:
> > 
> > > There is only one potential downside of this change and that is that 
> > > support for hardware floating point on the FPA will be limited to single 
> > > precision (unless you are on a big-endian machine -- which we don't have 
> > > anyway).  However, there is only one cpu (ARM7500FE) that has a fpa as 
> > > standard and even on that we currently make no use of the floating point 
> > > coprocessor.
> > 
> > I think this is slightly too pessimistic.  We could still take advantage
> > of an FPA, either by recompiling the world with -mhard-float or by making
> > the soft-float routines into wrappers which flipped the endianness while
> > transferring data to and from the FPA.  The latter, while unpleasant,
> > would only be slightly more unpleasant than it would be with FPA-order
> > doubles (two {ST,LD}Rs vs one {ST,LD}M).
[...]
> (basically, from a pseudo code perspective, we have to pretend that all 
> stores from fp regs to memory require doing so via a pair of integer regs.

I was referring to the case where the code uses -msoft-float, but libc
implements the soft-float routines in terms of FPA instructions.  In this
case, every FP op gets its arguments from integer registers and puts its
results in them, so the added overhead of word-swapping doubles is small.

If you're going to arrange to make it possible to link -msoft-float and
-mhard-float code together then things will obviously get painful.  This
won't work at present (they maintain FP exception stuff in different
places if nothing else), and I don't think it's a terribly important thing
to have.

-- 
Ben Harris                                                   <bjh21@netbsd.org>
Portmaster, NetBSD/arm26               <URL:http://www.netbsd.org/Ports/arm26/>