Hi folks,

I don't care too much about other FPA support code that may be around (I'd 
rather leave that for someone else to handle) but it seems reasonable to 
get rid of the definitions in <arm/ieee.h> and the support in libc (which 
would make the port switch over to using some MI files).  Are there any 
reasons not to, at this point?


- Klaus

----------  Forwarded Message  ----------

Subject: Re: CVS commit: src/sys/arch/arm/include
Date: Monday 27 October 2003 18:40
From: Richard Earnshaw <rearnsha@arm.com>
To: Klaus Klein <kleink@reziprozitaet.de>
Cc: Richard.Earnshaw@arm.com

> On Monday 27 October 2003 17:04, you wrote:
> > Before you pour too much effort into this, I'm wondering why you are
> > doing this at all (adding support for the FPA), unless it's for
> > building COMPAT versions of the libraries.  When we switched to ELF we
> > dropped support for FPA coprocessors (at least, for direct use by the
> > FPA) in favour of the pure-endian model used by the VFP.
> >
> > It's still possible to use an FPA as an accelerator for a soft-float
> > library, but that will not be seen directly by libc or anything outside
> > of the soft-float code.
>
> I was pretty much under the same impression, but it's not exactly as if I
> was adding FPA support.  I'm merely keeping what was here before; it's
> not as if this would cause further maintenance effort for what I'm
> currently pursuing (adding some of the C99 math library interfaces) with
> the right definitions in place.
>
> However, if you think those FPA definitions should be ditched now, I will
> gladly do so.
>
>
> - Klaus

I'm inclined to say yes.  The dual support was originally put in to ease
the transition from one ABI (a.out) to the other (ELF) when we switched
formats.  I very much doubt we would ever want to go back again.

However, we should probably ask port-arm for confirmation.  Feel free to
re-post the above.

R.

-------------------------------------------------------