> On Wed, 14 Feb 2001, Richard Earnshaw wrote:
> 
> > So, to the question.  If I knock up a hack to the compiler and assembler 
> > so that for NetBSD/ARM/ELF they change to a pure little-endian floating 
> > point format, would there be any objections?
> 
> I don't think I'd grumble very much, since it's clearly the right way to
> go.  I'd like -mhard-float still to work on FPA systems, though.

I would certainly make this work correctly when I do the changes to the 
main FSF sources.

> 
> > I haven't tested it, but I believe the patch to the compiler is trivial.  
> > In the arm/netbsd/elf header file, after including arm.h (probably 
> > indirectly), we simply add
> > 
> > #undef FLOAT_WORDS_BIG_ENDIAN
> 
> I think you need a way to switch this at runtime, so as to be able to
> support FPA-style hard-float as well.

Yes, for a full patch.

> 
> > For the assembler, for the rare cases where assembly language contains 
> > .double (gcc never generates this), we just have to change the following 
> > loop in md_atof() so that it spits out the `words' in the order 3210:
> 
> Hmm.  I suspect this means the assembler needs a run-time option to switch
> FP formats too.

Similarly.

I don't intend to (permanently) remove FPA support from the compiler, my 
intent was just to get something available quickly, so that when we move 
to ELF we switch the default to the new word endianness.  Since there 
seems to be pressure to move to ELF ASAP, I thought it important that we 
at least discussed this issue first (the ELF transition is probably the 
last chance we get to fix some of the current anomalies in the default 
ABI).

We can add back support for the FPA with a bit more leisure (since we 
currently don't support it at all).

R.