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).

> I see no good reason not to make this change, and several why we should.

Same here (and I speak as a man with more ARMs with FPAs than without).

> BTW, the current loss of -mhard-float for FPA code is a temporary issue 
> due to the fact that a full patch to support the new VFP format and 
> instructions will take a little bit longer to develop.  I fully intend to 
> maintain support for the FPA when I do a complete set of patches for VFP 
> support.

I suspect it shouldn't be too hard to make FPA support work properly again
without bothering with proper VFP instruction support.  I'll do it if I
get bored enough (it's in the bit of GCC I can understand).

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