Re: Deprecating ARM FPA support (was: ARM Neon Tests Failing on non-Neon Target)
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
Re: Deprecating ARM FPA support (was: ARM Neon Tests Failing on non-Neon Target)
On Mon, 2010-06-28 at 01:37 +0100, Martin Guy wrote: On 6/27/10, Gerald Pfeifer ger...@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)
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)
On 6/27/10, Gerald Pfeifer ger...@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 (was: ARM Neon Tests Failing on non-Neon Target)
On Sun, 2010-05-23 at 05:11 +0100, Martin Guy wrote: On 5/11/10, Mark Mitchell m...@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)
On Sun, 2010-05-23 at 23:15 +0200, Steven Bosscher wrote: On Sun, May 23, 2010 at 10:27 PM, Mark Mitchell m...@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)
On 5/24/10, Richard Earnshaw rearn...@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 m...@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)
On Mon, 2010-05-24 at 12:42 +0200, Steven Bosscher wrote: On 5/24/10, Richard Earnshaw rearn...@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 m...@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)
(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 jos...@codesourcery.com
Re: Deprecating ARM FPA support (was: ARM Neon Tests Failing on non-Neon Target)
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 jos...@codesourcery.com
Re: Deprecating ARM FPA support (was: ARM Neon Tests Failing on non-Neon Target)
On Mon, 2010-05-24 at 11:33 +, 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 (was: ARM Neon Tests Failing on non-Neon Target)
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 (was: ARM Neon Tests Failing on non-Neon Target)
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 m...@codesourcery.com (650) 331-3385 x713
Re: Deprecating ARM FPA support (was: ARM Neon Tests Failing on non-Neon Target)
On Sun, May 23, 2010 at 10:27 PM, Mark Mitchell m...@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
