Deprecating ARM FPA support (was: ARM Neon Tests Failing on non-Neon Target)

Deprecating ARM FPA support (was: ARM Neon Tests Failing on non-Neon Target)

[Martin Guy]

On 5/11/10, Mark Mitchell <mark@codesourcery.com> wrote:
> Richard Earnshaw wrote:
>
>  > Speaking of which, we should probably formally deprecate the old arm-elf
>  > derived targets in 4.6 so that we can remove them in 4.7.
>
>  > Similarly, we should deprecate support for the FPA on ARM.
>
>  I agree.

No one seems to have succeeded in getting arm-elf to work for some
years, so removing them seems to be no loss.

However, although no one currently sells FPA hardware, it is widely
supported as the only floating point model emulated by the Linux
kernel, and people have to use it when compiling stuff to run on OABI
systems, which include boards currently on the market based on ARMv4
(no t) such as the Balloon Board 2.0 as well as boards with more
recent CPUs where the manufacturer only supplies a LInux port for a
kernel version that predates EABI support such as the Armadillo range.

Dropping FPA support from GCC effectively makes the OABI unusable, and
often we are forced to use that by the environment supplied to us. Are
there significant advantages to removing FPA support, other than
reducing the size of the ARM backend?

     M

Re: Deprecating ARM FPA support (was: ARM Neon Tests Failing on non-Neon Target)

[Mark Mitchell]

Martin Guy wrote:

> Dropping FPA support from GCC effectively makes the OABI unusable, and
> often we are forced to use that by the environment supplied to us. Are
> there significant advantages to removing FPA support, other than
> reducing the size of the ARM backend?

I think that maintainability of the ARM backend is indeed the major
benefit to dropping it.  I'm surprised that people are still doing new
designs based on ARMv4 (not ARMv4T) systems, but if they are then I
suppose that's an argument for leaving the FPA bits hanging around.  On
the other hand, it's not an argument for not *deprecating* them.  We may
as well deprecate them now, and then we can remove them later.  The
actual removal won't happen until at least 4.7, which is probably
another couple of years away.

Thanks,

-- 
Mark Mitchell
CodeSourcery
mark@codesourcery.com
(650) 331-3385 x713

Re: Deprecating ARM FPA support (was: ARM Neon Tests Failing on non-Neon Target)

[Steven Bosscher]

On Sun, May 23, 2010 at 10:27 PM, Mark Mitchell <mark@codesourcery.com> wrote:
> Martin Guy wrote:
>
>> Dropping FPA support from GCC effectively makes the OABI unusable, and
>> often we are forced to use that by the environment supplied to us. Are
>> there significant advantages to removing FPA support, other than
>> reducing the size of the ARM backend?
>
> I think that maintainability of the ARM backend is indeed the major
> benefit to dropping it.

There are lots of other ports that could be dropped to improve
maintainability of some backends, or even the whole of GCC. That has
never been accepted as a good reason to drop anything if there are
still users of it, no matter how few (see pdp11 / vax backends,
osf/tru64 support, other random unmaintained backends, ...).

What is different about arm-elf?

Ciao!
Steven

Re: Deprecating ARM FPA support

[Mark Mitchell]

Steven Bosscher wrote:

> There are lots of other ports that could be dropped to improve
> maintainability of some backends, or even the whole of GCC. That has
> never been accepted as a good reason to drop anything if there are
> still users of it, no matter how few (see pdp11 / vax backends,
> osf/tru64 support, other random unmaintained backends, ...).
> 
> What is different about arm-elf?

Nothing is different about arm-elf or FPA.  But, it's always been my
feeling that we tried too hard to cater to ports with very few users.
In any case, please note that here we're talking about deprecating a
feature; whether to remove it is an independent decision for later.  I
think deprecation of FPA is reasonable; at what point removal is
reasonable isn't something we have to answer until *at least* the 4.7
release cycle.

-- 
Mark Mitchell
CodeSourcery
mark@codesourcery.com
(650) 331-3385 x713

Re: Deprecating ARM FPA support (was: ARM Neon Tests Failing on non-Neon Target)

[Richard Earnshaw]

On Sun, 2010-05-23 at 05:11 +0100, Martin Guy wrote:
> On 5/11/10, Mark Mitchell <mark@codesourcery.com> wrote:
> > Richard Earnshaw wrote:
> >
> >  > Speaking of which, we should probably formally deprecate the old arm-elf
> >  > derived targets in 4.6 so that we can remove them in 4.7.
> >
> >  > Similarly, we should deprecate support for the FPA on ARM.
> >
> >  I agree.
> 
> No one seems to have succeeded in getting arm-elf to work for some
> years, so removing them seems to be no loss.
> 

If nobody is building and testing it, then this will happen.  It's why
we should deprecate it.  That way, users are aware of the fact that the
configuration might not work and will probably go away at some point.

> However, although no one currently sells FPA hardware, 

That's overstating it.  Currently?  I don't expect anyone to ever sell
it again.

> it is widely
> supported as the only floating point model emulated by the Linux
> kernel, and people have to use it when compiling stuff to run on OABI
> systems, which include boards currently on the market based on ARMv4
> (no t) such as the Balloon Board 2.0 as well as boards with more
> recent CPUs where the manufacturer only supplies a LInux port for a
> kernel version that predates EABI support such as the Armadillo range.

OABI should be on the deprecated list too, as should all ports that
derive from the APCS or ATPCS rules.  The point of this deprecation
process is to allow us to sort out a lot of historical kinks in the
compiler.

Lets face it: strongarm was the last v4 chip to be produced, that's now
15 years old.  If gcc-4.6 were to be the last compiler to support it,
then it would still be supported for at least two years following its
release in (presumably) 2011 ie until at least 2013, by which time it
will be 18 years old.  I think that ought to be enough of a life-span.

> 
> Dropping FPA support from GCC effectively makes the OABI unusable, and
> often we are forced to use that by the environment supplied to us. Are
> there significant advantages to removing FPA support, other than
> reducing the size of the ARM backend?

Debian dropped OABI after Lenny, I've not heard anybody complain about
that.  That was the last major distro to use it.

Don't forget that the cost is not just on GCC, it's on all the tools --
gas, gdb, binutils -- the list goes on.

As for technical difficulties, then there's the odd format of doubles
that makes for much confusion for users, the mess of the old attributes
used in the old ABI variants and the fact that they were implemented
incorrectly...

It's time we faced up to the fact that the old code is not going to be
sorted out properly; that there's a maintained and well specified
compiler port out there that is not only capable of supporting v4 but is
also future-proofed as much as we can make it; that the old ports are
not being tested, so are most likely buggy by now and that all this
legacy bloat has a cost that we all must bear if we keep refusing to do
anything about it.

R.

Re: Deprecating ARM FPA support (was: ARM Neon Tests Failing on non-Neon Target)

[Richard Earnshaw]

On Sun, 2010-05-23 at 23:15 +0200, Steven Bosscher wrote:
> On Sun, May 23, 2010 at 10:27 PM, Mark Mitchell <mark@codesourcery.com> wrote:
> > Martin Guy wrote:
> >
> >> Dropping FPA support from GCC effectively makes the OABI unusable, and
> >> often we are forced to use that by the environment supplied to us. Are
> >> there significant advantages to removing FPA support, other than
> >> reducing the size of the ARM backend?
> >
> > I think that maintainability of the ARM backend is indeed the major
> > benefit to dropping it.
> 
> There are lots of other ports that could be dropped to improve
> maintainability of some backends, or even the whole of GCC. That has
> never been accepted as a good reason to drop anything if there are
> still users of it, no matter how few (see pdp11 / vax backends,
> osf/tru64 support, other random unmaintained backends, ...).
> 
> What is different about arm-elf?
> 

What's different is that there is a well-maintained arm-eabi port.  The
arm-elf port and all its legacy just gets in the way.

The vax back-end only affects VAX; likewise for the PDP11 port.

I think it's critical that we don't let the tail wag the dog here.

R.

Re: Deprecating ARM FPA support (was: ARM Neon Tests Failing on non-Neon Target)

[Steven Bosscher]

On 5/24/10, Richard Earnshaw <rearnsha@arm.com> wrote:
>
> On Sun, 2010-05-23 at 23:15 +0200, Steven Bosscher wrote:
>> On Sun, May 23, 2010 at 10:27 PM, Mark Mitchell <mark@codesourcery.com>
>> wrote:
>> > Martin Guy wrote:
>> >
>> >> Dropping FPA support from GCC effectively makes the OABI unusable, and
>> >> often we are forced to use that by the environment supplied to us. Are
>> >> there significant advantages to removing FPA support, other than
>> >> reducing the size of the ARM backend?
>> >
>> > I think that maintainability of the ARM backend is indeed the major
>> > benefit to dropping it.
>>
>> There are lots of other ports that could be dropped to improve
>> maintainability of some backends, or even the whole of GCC. That has
>> never been accepted as a good reason to drop anything if there are
>> still users of it, no matter how few (see pdp11 / vax backends,
>> osf/tru64 support, other random unmaintained backends, ...).
>>
>> What is different about arm-elf?
>>
>
> What's different is that there is a well-maintained arm-eabi port.  The
> arm-elf port and all its legacy just gets in the way.
>

Imho you are taking a too narrow view here, because...

> The vax back-end only affects VAX; likewise for the PDP11 port.

...all this legacy just gets in the way of gcc as a whole. So I still
don't see the difference.

Nb, I don't oppose deprecating any arm stuff, but I just would like to
know if the justification also applies to other backends/ports.
Patched from me and others were rejected in the past even though the
situation was similar. Under what criteria would such patches now get
support from the RMs?

> I think it's critical that we don't let the tail wag the dog here.

Don't know what this means...

Ciao!
Steven

Re: Deprecating ARM FPA support (was: ARM Neon Tests Failing on non-Neon Target)

[Richard Earnshaw]

On Mon, 2010-05-24 at 12:42 +0200, Steven Bosscher wrote:
> On 5/24/10, Richard Earnshaw <rearnsha@arm.com> wrote:
> >
> > On Sun, 2010-05-23 at 23:15 +0200, Steven Bosscher wrote:
> >> On Sun, May 23, 2010 at 10:27 PM, Mark Mitchell <mark@codesourcery.com>
> >> wrote:
> >> > Martin Guy wrote:
> >> >
> >> >> Dropping FPA support from GCC effectively makes the OABI unusable, and
> >> >> often we are forced to use that by the environment supplied to us. Are
> >> >> there significant advantages to removing FPA support, other than
> >> >> reducing the size of the ARM backend?
> >> >
> >> > I think that maintainability of the ARM backend is indeed the major
> >> > benefit to dropping it.
> >>
> >> There are lots of other ports that could be dropped to improve
> >> maintainability of some backends, or even the whole of GCC. That has
> >> never been accepted as a good reason to drop anything if there are
> >> still users of it, no matter how few (see pdp11 / vax backends,
> >> osf/tru64 support, other random unmaintained backends, ...).
> >>
> >> What is different about arm-elf?
> >>
> >
> > What's different is that there is a well-maintained arm-eabi port.  The
> > arm-elf port and all its legacy just gets in the way.
> >
> 
> Imho you are taking a too narrow view here, because...
> 
> > The vax back-end only affects VAX; likewise for the PDP11 port.
> 
> ...all this legacy just gets in the way of gcc as a whole. So I still
> don't see the difference.
> 

To a degree, yes, you are right.  However, the source for all that port
is in separate files.  For the ARM port this is all necessarily in one
place.

> Nb, I don't oppose deprecating any arm stuff, but I just would like to
> know if the justification also applies to other backends/ports.
> Patched from me and others were rejected in the past even though the
> situation was similar. Under what criteria would such patches now get
> support from the RMs?
> 

Can't really answer that one.  I don't remember the case; and anyway,
it's not me that gets to decide...


R

Re: Deprecating ARM FPA support (was: ARM Neon Tests Failing on non-Neon Target)

[Joseph S. Myers]

(I've CC:ed the listed GCC maintainers for various OS ports whose ARM 
configurations in GCC do not appear to be using EABI, as well as Pedro for 
WinCE, given the discussions of deprecation.)  Deprecations are generally 
a matter for the relevant maintainers, which in this case means target 
maintainers together with OS maintainers (or target maintainers alone if 
noone is maintaining the OS ports to ARM).

On Mon, 24 May 2010, Richard Earnshaw wrote:

> OABI should be on the deprecated list too, as should all ports that
> derive from the APCS or ATPCS rules.  The point of this deprecation
> process is to allow us to sort out a lot of historical kinks in the
> compiler.

What ABI does WinCE use?  I don't think it's EABI-based; it's not even 
ELF.  When you're dealing with an OS not built with GCC, GCC gets to 
follow the ABI defined for that OS, just like the x86_64 Windows port has 
to deal with ABI differences from the ELF psABI for x86_64, for example.

For OSes built with GCC (which I think is all the non-WinCE ARM targets) 
there is more of a scope for transitioning to a new ABI and not supporting 
old OS versions (and so removing arm-linux, arm-elf).

I recently noted that VxWorks is not yet using EABI - but is certainly 
still supporting ARM.  Now, if it transitions, I think it was established 
some years ago that GCC does not generally try to support older VxWorks 
versions.

Is the ARM RTEMS port going to move to EABI?

Are the ARM ports of FreeBSD or NetBSD moving to EABI?  (I think we can 
kill the arm*-*-netbsd* that don't match arm*-*-netbsdelf* - i.e., old 
a.out-based NetBSD - and more generally any other a.out BSD ports.)  Old 
in-tree GCC versions shouldn't be a limitation here - 4.1 has EABI 
support.

Is there anyone maintaining arm*-*-ecos-elf?

I hope none of the above ports are using FPA.

-- 
Joseph S. Myers
joseph@codesourcery.com

Re: Deprecating ARM FPA support (was: ARM Neon Tests Failing on non-Neon Target)

[Joseph S. Myers]

On Mon, 24 May 2010, Steven Bosscher wrote:

> > The vax back-end only affects VAX; likewise for the PDP11 port.
> 
> ...all this legacy just gets in the way of gcc as a whole. So I still
> don't see the difference.
> 
> Nb, I don't oppose deprecating any arm stuff, but I just would like to
> know if the justification also applies to other backends/ports.
> Patched from me and others were rejected in the past even though the
> situation was similar. Under what criteria would such patches now get
> support from the RMs?

I don't think it's generally an RM matter; it's a matter for the relevant 
architecture and OS port maintainers (and for bare-metal targets such as 
arm-elf that means the architecture maintainers; likewise for -linux-gnu* 
targets since there is no separate GNU/Linux target maintainer).

What the responsibilities of maintainers are - whether it can be expected 
that target maintainers (or maintainers of other components) will do some 
defined cleanup or API change in some defined time with the targets 
otherwise liable to deprecation - is certainly a reasonable topic for 
discussion.  We were going to deprecate the targets not updated for IRA, 
but then a solution was produced that didn't require each target to be 
updated by its maintainer to continue to build....

-- 
Joseph S. Myers
joseph@codesourcery.com

Re: Deprecating ARM FPA support

[Joel Sherrill]

On 05/24/2010 06:33 AM, Joseph S. Myers wrote:
> (I've CC:ed the listed GCC maintainers for various OS ports whose ARM
> configurations in GCC do not appear to be using EABI, as well as Pedro for
> WinCE, given the discussions of deprecation.)  Deprecations are generally
> a matter for the relevant maintainers, which in this case means target
> maintainers together with OS maintainers (or target maintainers alone if
> noone is maintaining the OS ports to ARM).
>
> On Mon, 24 May 2010, Richard Earnshaw wrote:
>
>    
>> OABI should be on the deprecated list too, as should all ports that
>> derive from the APCS or ATPCS rules.  The point of this deprecation
>> process is to allow us to sort out a lot of historical kinks in the
>> compiler.
>>      
> What ABI does WinCE use?  I don't think it's EABI-based; it's not even
> ELF.  When you're dealing with an OS not built with GCC, GCC gets to
> follow the ABI defined for that OS, just like the x86_64 Windows port has
> to deal with ABI differences from the ELF psABI for x86_64, for example.
>
> For OSes built with GCC (which I think is all the non-WinCE ARM targets)
> there is more of a scope for transitioning to a new ABI and not supporting
> old OS versions (and so removing arm-linux, arm-elf).
>
> I recently noted that VxWorks is not yet using EABI - but is certainly
> still supporting ARM.  Now, if it transitions, I think it was established
> some years ago that GCC does not generally try to support older VxWorks
> versions.
>
> Is the ARM RTEMS port going to move to EABI?
>
>    
We are watching this discussion and see where it leads us.
RTEMS targets are normally one side-step from XXX-elf and
that was what lead us to use arm-elf.  If it has issues that
make it not the preferred target for embedded ARM work,
then we will need to move.  We have transitioned from COFF
to ELF in the past for similar reasons.

I think I triggered this discussion by asking why so many
tests failed on arm-rtems that had nothing to do with
anything RTEMS could break.   If it takes moving to arm-eabi
to get a well supported target that passes tests, we will
move.  We compile everything from source.

The question we would like answered is what impact this
has on our code base.  What changes will we have to
make to accomodate this?  Register usage changes, stack
frame changes, etc.
> Are the ARM ports of FreeBSD or NetBSD moving to EABI?  (I think we can
> kill the arm*-*-netbsd* that don't match arm*-*-netbsdelf* - i.e., old
> a.out-based NetBSD - and more generally any other a.out BSD ports.)  Old
> in-tree GCC versions shouldn't be a limitation here - 4.1 has EABI
> support.
>
> Is there anyone maintaining arm*-*-ecos-elf?
>
> I hope none of the above ports are using FPA.
>
>    
--joel

Re: Deprecating ARM FPA support

[Joseph S. Myers]

On Mon, 24 May 2010, Joel Sherrill wrote:

> The question we would like answered is what impact this
> has on our code base.  What changes will we have to
> make to accomodate this?  Register usage changes, stack
> frame changes, etc.

For ARM Linux, one change was dealing with __arm__ conditionals in code 
that related to the peculiarities of OABI structure layout - EABI is much 
more conventionally like other architectures in that regard.  I don't know 
whether that will apply to RTEMS (as I'm not familiar with the details of 
the various old ABIs).

-- 
Joseph S. Myers
joseph@codesourcery.com

Re: Deprecating ARM FPA support (was: ARM Neon Tests Failing on non-Neon Target)

[Richard Earnshaw]

On Mon, 2010-05-24 at 11:33 +0000, Joseph S. Myers wrote:
> (I've CC:ed the listed GCC maintainers for various OS ports whose ARM 
> configurations in GCC do not appear to be using EABI, as well as Pedro for 
> WinCE, given the discussions of deprecation.)  Deprecations are generally 
> a matter for the relevant maintainers, which in this case means target 
> maintainers together with OS maintainers (or target maintainers alone if 
> noone is maintaining the OS ports to ARM).
> 
> On Mon, 24 May 2010, Richard Earnshaw wrote:
> 
> > OABI should be on the deprecated list too, as should all ports that
> > derive from the APCS or ATPCS rules.  The point of this deprecation
> > process is to allow us to sort out a lot of historical kinks in the
> > compiler.
> 
> What ABI does WinCE use?  

Don't know.  Does a document specifying it even exist?  If we are
supporting an ABI, then I think we need to have a publicly available
SPEC.

> I don't think it's EABI-based; it's not even 
> ELF.  When you're dealing with an OS not built with GCC, GCC gets to 
> follow the ABI defined for that OS, just like the x86_64 Windows port has 
> to deal with ABI differences from the ELF psABI for x86_64, for example.
> 
> For OSes built with GCC (which I think is all the non-WinCE ARM targets) 
> there is more of a scope for transitioning to a new ABI and not supporting 
> old OS versions (and so removing arm-linux, arm-elf).
> 
> I recently noted that VxWorks is not yet using EABI - but is certainly 
> still supporting ARM.  Now, if it transitions, I think it was established 
> some years ago that GCC does not generally try to support older VxWorks 
> versions.
> 
> Is the ARM RTEMS port going to move to EABI?

Ask the maintainers.  Do they still want their OS to work on modern CPUs
with any degree of efficiency?  The current ABI diverged from the old
for good technical reasons, not just for the sake of being different.

> 
> Are the ARM ports of FreeBSD or NetBSD moving to EABI?  (I think we can 
> kill the arm*-*-netbsd* that don't match arm*-*-netbsdelf* - i.e., old 
> a.out-based NetBSD - and more generally any other a.out BSD ports.)  Old 
> in-tree GCC versions shouldn't be a limitation here - 4.1 has EABI 
> support.

The NetBSD developers said at the time that they moved to arm-netbsdelf
that the ABI was transitional and that they would move to the EABI once
it was finished.  They've not made much effort to do that move (though I
admit as a NetBSD developer, I've not done much pushing).  Consider this
the first heave :-)  I don't know about FreeBSD; and I'm not aware that
they've ever done anything other than follow NetBSD in this area.

> 
> Is there anyone maintaining arm*-*-ecos-elf?
> 
> I hope none of the above ports are using FPA.

I don't think so.  Certainly NetBSD doesn't; I can't speak for the rest.
In fact, I'm pretty sure that only the old linux ABI uses the FPA.

Certainly removing support for FPA (and any targets that require it) as
a first step would be an option; but we should also focus on where we
want to get to.  Setting our plans out would be the best option for
those who need to change, so that they have sufficient opportunity to
plan their own work and avoid unnecessary intermediate steps (it would
be very unfair, for example, to suggest to those who need to migrate
away from using the FPA to just move to using soft-float arm-elf if they
then find twelve months down the line that they have to move again
because arm-elf was going away as well.

R.

> 

Re: Deprecating ARM FPA support

[Richard Earnshaw]

On Mon, 2010-05-24 at 06:40 -0500, Joel Sherrill wrote:
> The question we would like answered is what impact this
> has on our code base.  What changes will we have to
> make to accomodate this?  Register usage changes, stack
> frame changes, etc.

By far the biggest change is to the layout of 64-bit data types.  These
now have 64-bit alignment and this has consequences for stack alignment,
struct layout and argument marshalling.  There are many other small
changes (probably too many to enumerate with any hope of not missing
one), but they are mostly small.

R.

Re: Deprecating ARM FPA support (was: ARM Neon Tests Failing on non-Neon Target)

[Richard Kenner]

> What's different is that there is a well-maintained arm-eabi port.  The
> arm-elf port and all its legacy just gets in the way.
> 
> The vax back-end only affects VAX; likewise for the PDP11 port.

I think that's a critical distinction.  I can't see removing a port
just because it's not used much (or at all) because it might be
valuable for historical reason or to show examples for how to do things.
If the maintenance burden of keeping that port is just doing some mechanical
changes a couple of times a year when the backend API changes, that
port should be kept even if there are ZERO known users.

But if it's interfering with the maintenance of an active port with
which it shares code, then I think it's retention has to meet a higher
standard of usefulness.

Re: Deprecating ARM FPA support

[Mark Mitchell]

Richard Earnshaw wrote:

> Don't know.  Does a document specifying it even exist?  If we are
> supporting an ABI, then I think we need to have a publicly available
> SPEC.

I disagree with that statement.  If a system is sufficiently popular, we
probably want to support it -- with or without a specification.  For
example, if x86 Windows didn't have a public ABI specification, we'd
still want to support it.

> I don't think so.  Certainly NetBSD doesn't; I can't speak for the rest.
> In fact, I'm pretty sure that only the old linux ABI uses the FPA.

I'm certain VxWorks makes no use of FPA.  However, whether it changes to
EABI or not is not purely up to the GCC maintainers; Wind River uses the
Diab compiler on VxWorks as well, and VxWorks is an environment where
stability over time is considered very important.  On the other hand,
it's going to be a long time before VxWorks gets to GCC 4.7, so there's
time to work this out.

> Certainly removing support for FPA (and any targets that require it) as
> a first step would be an option; but we should also focus on where we
> want to get to.

I agree with that.  But, it would also be interesting to know just how
broken that code is.  If, in fact, FPA and/or ARM ELF mostly work at
present, then there's less call for actually removing (as opposed to
deprecating) things.  If, on the other hand, they've been broken for
several releases, then there's good evidence that nobody really cares
about new versions of GCC supporting these things.

-- 
Mark Mitchell
CodeSourcery
mark@codesourcery.com
(650) 331-3385 x713

Re: Deprecating ARM FPA support

[Martin Guy]

On 5/24/10, Mark Mitchell <mark@codesourcery.com> wrote:
>  > Certainly removing support for FPA (and any targets that require it) as
>  > a first step would be an option; but we should also focus on where we
>  > want to get to.
>
>  I agree with that.  But, it would also be interesting to know just how
>  broken that code is.  If, in fact, FPA and/or ARM ELF mostly work at
>  present, then there's less call for actually removing (as opposed to
>  deprecating) things.

FPA code generation is 100% good AFAIK, and has been used intensively
for years (as the FPU model for all gnu/linux ports before EABI).

Maverick is the one that has never worked since it was submitted; I
have patches that make it 100% good (well, ok, no known failure cases)
but don't know how to get them into mainline.

    M

Re: Deprecating ARM FPA support (was: ARM Neon Tests Failing on non-Neon Target)

[Gerald Pfeifer]

On Mon, 24 May 2010, Richard Kenner wrote:
> I think that's a critical distinction.  I can't see removing a port just 
> because it's not used much (or at all) because it might be valuable for 
> historical reason or to show examples for how to do things. If the 
> maintenance burden of keeping that port is just doing some mechanical 
> changes a couple of times a year when the backend API changes, that port 
> should be kept even if there are ZERO known users.

Nothing in life is free, and certainly those "mechanical changes a 
couple of times a year" are not.  Plus we do have been using version
control systems for more than a decade, so indeed I'd say a port with
zero known users should actually be removed.  As should a port that
is not maintained, of course.

Gerald

Re: Deprecating ARM FPA support (was: ARM Neon Tests Failing on non-Neon Target)

[Martin Guy]

On 6/27/10, Gerald Pfeifer <gerald@pfeifer.com> wrote:
> On Mon, 24 May 2010, Richard Kenner wrote:
>  > I think that's a critical distinction.  I can't see removing a port just
>  > because it's not used much (or at all) because it might be valuable for
>  > historical reason or to show examples for how to do things.
>
>  I'd say a port with
>  zero known users should actually be removed.

FPA is very widely used. From day 0 until 2006 it was the only FP
model emulated by the Linux kernel and so in required by all operating
systems created up to that date.
  Actively-maintained software distributions and recent ports of Linux
tend to use a different ABI ("EABI") whose default FP model is
user-space softfloat and does not require FPA code generation
(thankfully!), however there are many exiting software distributions
in current use that only support emulated hard FPA instructions. For
ARM boards without mainline Linux support whose manufacturers' kernel
ports predates 2.6.16, it is mandatory, as is also is for users who
just want to compile code for a given existing system that happens not
to be running a recent kernel and userspace.

     M

Re: Deprecating ARM FPA support

[Mark Mitchell]

Martin Guy wrote:

> For
> ARM boards without mainline Linux support whose manufacturers' kernel
> ports predates 2.6.16, it is mandatory, as is also is for users who
> just want to compile code for a given existing system that happens not
> to be running a recent kernel and userspace.

But what are the chances that GCC 4.7 (the first release in which FPA
would actually be removed, and probably not released until about two
years from now) is actually useful on this system?  It's very unlikely
that GCC 4.7 will successfully compile the 2.6.16 kernel, or, I would
expect, a lot of userspace applications.

My feeling is that it makes sense to deprecate this now, which allows us
in the 4.7 cycle to decide whether or not to remove the functionality.
If we decide then that it's still needed, we can always keep it.  But,
if we don't deprecate it now, then our policy is that we can't remove it.

-- 
Mark Mitchell
CodeSourcery
mark@codesourcery.com
(650) 331-3385 x713

Re: Deprecating ARM FPA support (was: ARM Neon Tests Failing on non-Neon Target)

[Richard Earnshaw]

On Mon, 2010-06-28 at 01:37 +0100, Martin Guy wrote:
> On 6/27/10, Gerald Pfeifer <gerald@pfeifer.com> wrote:
> > On Mon, 24 May 2010, Richard Kenner wrote:
> >  > I think that's a critical distinction.  I can't see removing a port just
> >  > because it's not used much (or at all) because it might be valuable for
> >  > historical reason or to show examples for how to do things.
> >
> >  I'd say a port with
> >  zero known users should actually be removed.
> 
> FPA is very widely used. From day 0 until 2006 it was the only FP
> model emulated by the Linux kernel and so in required by all operating
> systems created up to that date.

Apart from all those sensible people who'd already moved to a pure
soft-float world.

>   Actively-maintained software distributions and recent ports of Linux
> tend to use a different ABI ("EABI") whose default FP model is
> user-space softfloat and does not require FPA code generation
> (thankfully!), however there are many exiting software distributions
> in current use that only support emulated hard FPA instructions. 

There's only one main distribution, Debian.  That's dropped the old ABI
as of Sid, and by the time 4.7 comes out Lenny will be well on the road
to obsolete.

> For
> ARM boards without mainline Linux support whose manufacturers' kernel
> ports predates 2.6.16, it is mandatory, as is also is for users who
> just want to compile code for a given existing system that happens not
> to be running a recent kernel and userspace.
> 

Most of these minor boards are using soft float (at least, if they have
any sense).  The only part that really used the FPA was the 7500FE, but
that's been off the market for a long time now.

R.

Re: Deprecating ARM FPA support (was: ARM Neon Tests Failing on non-Neon Target)

[Paul Brook]

> However, although no one currently sells FPA hardware, it is widely
> supported as the only floating point model emulated by the Linux
> kernel, and people have to use it when compiling stuff to run on OABI
> systems, which include boards currently on the market based on ARMv4
> (no t) such as the Balloon Board 2.0 as well as boards with more
> recent CPUs where the manufacturer only supplies a LInux port for a
> kernel version that predates EABI support such as the Armadillo range.

Armv4 (not t) targets are supported by EABI targets via the --fix-v4bx option.  
You have to decide which you're targeting at static link time (v4t 
interworking for EABI compliance or armv4), but once you make that decision it 
should support everything the OABI port did.

In theory you can use --fix-v4bx-interworking to generate armv4 binaries that 
are fully EABI compliant, however this comes at significant cost, and you eed 
to tweak a couple of the libgcc assembly routines.

Paul