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

Actually, I think it would be horrendous.  Don't forget that doubles can 
be passed around by reference and as part of structures.  Because of this, 
we basically have to make all doubles in memory (except perhaps spilled 
pseudo registers) take the same endianness.  The implication is that every 
load to a double FPA register would need the sequence

ldr	ra, [base]
ldr	rb, [base+4]
stmfd	sp!, {rb, ra}
ldfd	fx, [sp], #8

and every store would have to do the equivalent in reverse.

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

Good.

R.