On Sat, 2011-06-04 at 20:53 -0400, Jon Masters wrote:
[0] We're making a "one time" incompatible ABI switch in F-15 bringup to the "hard float" ABI defined in section 6 of the ARM AAPCS (commonly referred to as the ARM EABI - but that doesn't actually exist as a name). The procedure call standard will be ARM AAPCS vfpv3-d16, as defined in section 6 of that document. Other distros are switching and this will form the basis of any LSB standardization effort later on. Think of v7 and v5 as being different arches, which they are really.
And to further clarify:
- This is an addition, not a switch -- the intention is to continue to support armv5tel in addition to armv7hl at this time -- Tegra and Marvell Kirkwood (including plug computer) devices which do not support armv7hl will continue to work with armv5tel.
- The significant incompatibility is hardfp vs. softfp ABI (moreso than v7 vs. v5).
-- Chris
On Sat, 2011-06-04 at 21:10 -0400, Chris Tyler wrote:
On Sat, 2011-06-04 at 20:53 -0400, Jon Masters wrote:
[0] We're making a "one time" incompatible ABI switch in F-15 bringup to the "hard float" ABI defined in section 6 of the ARM AAPCS (commonly referred to as the ARM EABI - but that doesn't actually exist as a name). The procedure call standard will be ARM AAPCS vfpv3-d16, as defined in section 6 of that document. Other distros are switching and this will form the basis of any LSB standardization effort later on. Think of v7 and v5 as being different arches, which they are really.
And to further clarify:
- This is an addition, not a switch -- the intention is to continue to
support armv5tel in addition to armv7hl at this time -- Tegra and Marvell Kirkwood (including plug computer) devices which do not support armv7hl will continue to work with armv5tel.
- The significant incompatibility is hardfp vs. softfp ABI (moreso than
v7 vs. v5).
Thanks. Indeed, my separate arch comment is really that v7 (with assumed hardfp that will be the case in the form of ABI used) and v5 without hardfp do not use the same ABI calling convention. But for simplification, I called them "different arches".
We'll keep v5 around. I think longer term, it probably makes sense to kill it off once people have moved to newer boards/systems (like older versions of IA32 have been killed off over time). But again, that will depend on who is using v5, etc. over time.
Jon.
Jon Masters jcm@redhat.com writes:
We'll keep v5 around. I think longer term, it probably makes sense to kill it off once people have moved to newer boards/systems (like older versions of IA32 have been killed off over time). But again, that will depend on who is using v5, etc. over time.
That kill-off of older x86 models made sense when you could effectively no longer purchase said systems, and couldn't purchase them for several years. When pretty much all you COULD purchase was an i686, and that had been the case for years, *then* it made sense to stop i386 support.
I feel the same way about armv5tel. If Sheeva/Kirkwood stops using v5 then sure, I feel dropping v5 support would be fine sometime later.
Jon.
-derek
On Sun, Jun 5, 2011 at 2:10 AM, Chris Tyler chris@tylers.info wrote:
On Sat, 2011-06-04 at 20:53 -0400, Jon Masters wrote:
[0] We're making a "one time" incompatible ABI switch in F-15 bringup to the "hard float" ABI defined in section 6 of the ARM AAPCS (commonly referred to as the ARM EABI - but that doesn't actually exist as a name). The procedure call standard will be ARM AAPCS vfpv3-d16, as defined in section 6 of that document. Other distros are switching and this will form the basis of any LSB standardization effort later on. Think of v7 and v5 as being different arches, which they are really.
And to further clarify:
- This is an addition, not a switch -- the intention is to continue to
support armv5tel in addition to armv7hl at this time -- Tegra and Marvell Kirkwood (including plug computer) devices which do not support armv7hl will continue to work with armv5tel.
Err Tegra should be supported due to the use of vfpv3-d16? Correct?
Peter
On 06/05/2011 09:54 AM, Peter Robinson wrote:
On Sun, Jun 5, 2011 at 2:10 AM, Chris Tylerchris@tylers.info wrote:
On Sat, 2011-06-04 at 20:53 -0400, Jon Masters wrote:
[0] We're making a "one time" incompatible ABI switch in F-15 bringup to the "hard float" ABI defined in section 6 of the ARM AAPCS (commonly referred to as the ARM EABI - but that doesn't actually exist as a name). The procedure call standard will be ARM AAPCS vfpv3-d16, as defined in section 6 of that document. Other distros are switching and this will form the basis of any LSB standardization effort later on. Think of v7 and v5 as being different arches, which they are really.
And to further clarify:
- This is an addition, not a switch -- the intention is to continue to
support armv5tel in addition to armv7hl at this time -- Tegra and Marvell Kirkwood (including plug computer) devices which do not support armv7hl will continue to work with armv5tel.
Err Tegra should be supported due to the use of vfpv3-d16? Correct?
I think Chris wanted to see NEON as standard on armv7. I already voiced my disagreement to that in an earlier post. Since NEON packages can be used on any hardfp platform that supports NEON, I think NEON enabling should be handled on a package-by-package basis. It seems like a sounder trade-off for the sake of "rpmbuild --rebuild" with a different .rpmrc file.
Gordan
On Sun, Jun 5, 2011 at 12:22 PM, Gordan Bobic gordan@bobich.net wrote:
On 06/05/2011 09:54 AM, Peter Robinson wrote:
On Sun, Jun 5, 2011 at 2:10 AM, Chris Tylerchris@tylers.info wrote:
On Sat, 2011-06-04 at 20:53 -0400, Jon Masters wrote:
[0] We're making a "one time" incompatible ABI switch in F-15 bringup to the "hard float" ABI defined in section 6 of the ARM AAPCS (commonly referred to as the ARM EABI - but that doesn't actually exist as a name). The procedure call standard will be ARM AAPCS vfpv3-d16, as defined in section 6 of that document. Other distros are switching and this will form the basis of any LSB standardization effort later on. Think of v7 and v5 as being different arches, which they are really.
And to further clarify:
- This is an addition, not a switch -- the intention is to continue to
support armv5tel in addition to armv7hl at this time -- Tegra and Marvell Kirkwood (including plug computer) devices which do not support armv7hl will continue to work with armv5tel.
Err Tegra should be supported due to the use of vfpv3-d16? Correct?
I think Chris wanted to see NEON as standard on armv7. I already voiced my disagreement to that in an earlier post. Since NEON packages can be used on any hardfp platform that supports NEON, I think NEON enabling should be handled on a package-by-package basis. It seems like a sounder trade-off for the sake of "rpmbuild --rebuild" with a different .rpmrc file.
Neon and hardfp are completely mutually exclusive. You can have one with out the other in both cases (NEON on softfp, no NEON with hardfp). The discussion above is above its to do solely with the hardfp platform bringup and nothing to do with NEON at all. Packages can be optimised for NEON at a later point (on both hardfp and softfp platforms).
Peter
Peter
On 06/05/2011 12:26 PM, Peter Robinson wrote:
On Sun, Jun 5, 2011 at 12:22 PM, Gordan Bobicgordan@bobich.net wrote:
On 06/05/2011 09:54 AM, Peter Robinson wrote:
On Sun, Jun 5, 2011 at 2:10 AM, Chris Tylerchris@tylers.info wrote:
On Sat, 2011-06-04 at 20:53 -0400, Jon Masters wrote:
[0] We're making a "one time" incompatible ABI switch in F-15 bringup to the "hard float" ABI defined in section 6 of the ARM AAPCS (commonly referred to as the ARM EABI - but that doesn't actually exist as a name). The procedure call standard will be ARM AAPCS vfpv3-d16, as defined in section 6 of that document. Other distros are switching and this will form the basis of any LSB standardization effort later on. Think of v7 and v5 as being different arches, which they are really.
And to further clarify:
- This is an addition, not a switch -- the intention is to continue to
support armv5tel in addition to armv7hl at this time -- Tegra and Marvell Kirkwood (including plug computer) devices which do not support armv7hl will continue to work with armv5tel.
Err Tegra should be supported due to the use of vfpv3-d16? Correct?
I think Chris wanted to see NEON as standard on armv7. I already voiced my disagreement to that in an earlier post. Since NEON packages can be used on any hardfp platform that supports NEON, I think NEON enabling should be handled on a package-by-package basis. It seems like a sounder trade-off for the sake of "rpmbuild --rebuild" with a different .rpmrc file.
Neon and hardfp are completely mutually exclusive. You can have one with out the other in both cases (NEON on softfp, no NEON with hardfp).
Hmm... My understanding that NEON SIMD is hardfp only.
Gordan
[0] We're making a "one time" incompatible ABI switch in F-15 bringup to the "hard float" ABI defined in section 6 of the ARM AAPCS (commonly referred to as the ARM EABI - but that doesn't actually exist as a name). The procedure call standard will be ARM AAPCS vfpv3-d16, as defined in section 6 of that document. Other distros are switching and this will form the basis of any LSB standardization effort later on. Think of v7 and v5 as being different arches, which they are really.
And to further clarify:
- This is an addition, not a switch -- the intention is to continue to
support armv5tel in addition to armv7hl at this time -- Tegra and Marvell Kirkwood (including plug computer) devices which do not support armv7hl will continue to work with armv5tel.
Err Tegra should be supported due to the use of vfpv3-d16? Correct?
I think Chris wanted to see NEON as standard on armv7. I already voiced my disagreement to that in an earlier post. Since NEON packages can be used on any hardfp platform that supports NEON, I think NEON enabling should be handled on a package-by-package basis. It seems like a sounder trade-off for the sake of "rpmbuild --rebuild" with a different .rpmrc file.
Neon and hardfp are completely mutually exclusive. You can have one with out the other in both cases (NEON on softfp, no NEON with hardfp).
Hmm... My understanding that NEON SIMD is hardfp only.
It is so much in that its only supported on Cortex A8 and later devices all of which are hardfp capable but it doesn't mean it can't be used when the device that supports it is running softfp.
Peter
On Sun, 2011-06-05 at 09:54 +0100, Peter Robinson wrote:
On Sun, Jun 5, 2011 at 2:10 AM, Chris Tyler chris@tylers.info wrote:
On Sat, 2011-06-04 at 20:53 -0400, Jon Masters wrote:
[0] We're making a "one time" incompatible ABI switch in F-15 bringup to the "hard float" ABI defined in section 6 of the ARM AAPCS (commonly referred to as the ARM EABI - but that doesn't actually exist as a name). The procedure call standard will be ARM AAPCS vfpv3-d16, as defined in section 6 of that document. Other distros are switching and this will form the basis of any LSB standardization effort later on. Think of v7 and v5 as being different arches, which they are really.
And to further clarify:
- This is an addition, not a switch -- the intention is to continue to
support armv5tel in addition to armv7hl at this time -- Tegra and Marvell Kirkwood (including plug computer) devices which do not support armv7hl will continue to work with armv5tel.
Err Tegra should be supported due to the use of vfpv3-d16? Correct?
(Trimming to ARM list only)
Tegra 2 and Tegra 3 are v7 (Cortex A9 MPcore) but the earlier Tegra chips (Tegra APX, Tegra 6XX ) are v6 (ARM11).
-Chris
On Sun, Jun 5, 2011 at 2:44 PM, Chris Tyler chris@tylers.info wrote:
On Sun, 2011-06-05 at 09:54 +0100, Peter Robinson wrote:
On Sun, Jun 5, 2011 at 2:10 AM, Chris Tyler chris@tylers.info wrote:
On Sat, 2011-06-04 at 20:53 -0400, Jon Masters wrote:
[0] We're making a "one time" incompatible ABI switch in F-15 bringup to the "hard float" ABI defined in section 6 of the ARM AAPCS (commonly referred to as the ARM EABI - but that doesn't actually exist as a name). The procedure call standard will be ARM AAPCS vfpv3-d16, as defined in section 6 of that document. Other distros are switching and this will form the basis of any LSB standardization effort later on. Think of v7 and v5 as being different arches, which they are really.
And to further clarify:
- This is an addition, not a switch -- the intention is to continue to
support armv5tel in addition to armv7hl at this time -- Tegra and Marvell Kirkwood (including plug computer) devices which do not support armv7hl will continue to work with armv5tel.
Err Tegra should be supported due to the use of vfpv3-d16? Correct?
(Trimming to ARM list only)
Tegra 2 and Tegra 3 are v7 (Cortex A9 MPcore) but the earlier Tegra chips (Tegra APX, Tegra 6XX ) are v6 (ARM11).
Thanks for the update. So to confirm we will support Tegra 2 on hardfp?
Peter
On Sun, 2011-06-05 at 09:54 +0100, Peter Robinson wrote:
On Sun, Jun 5, 2011 at 2:10 AM, Chris Tyler chris@tylers.info wrote:
On Sat, 2011-06-04 at 20:53 -0400, Jon Masters wrote:
[0] We're making a "one time" incompatible ABI switch in F-15 bringup to the "hard float" ABI defined in section 6 of the ARM AAPCS (commonly referred to as the ARM EABI - but that doesn't actually exist as a name). The procedure call standard will be ARM AAPCS vfpv3-d16, as defined in section 6 of that document. Other distros are switching and this will form the basis of any LSB standardization effort later on. Think of v7 and v5 as being different arches, which they are really.
And to further clarify:
- This is an addition, not a switch -- the intention is to continue to
support armv5tel in addition to armv7hl at this time -- Tegra and Marvell Kirkwood (including plug computer) devices which do not support armv7hl will continue to work with armv5tel.
Err Tegra should be supported due to the use of vfpv3-d16? Correct?
Right. v7 based Tegra parts will be supported by virtue of the vfpv3-d16 ABI (some newer VFPv3 parts have 16 additional optional registers not required by the minimal implementation we are basing upon in Fedora, intentionally, for ABI linkage, so that there's no break again). Don't worry about NEON, that's not something we're actively looking at yet, and when/if it does happen, it'll be implemented using caps to provide optimizations in certain places - it's not required or part of the ABI.
Basically, if it's a properly implemented ARMv7 part it should be supportable by the hardfp port. One of the the things that has happened in recent times is the move toward much more standardized minimal hardware features that can be generically targeted. I believe this is a trend that we will see continued. Standardization is a good thing :)
In case it helps Gordan and anyone else:
1). We're talking about a minimal configuration for hardfp. Assuming: - Cortex A(8) profile ARMv7 compatible parts and later - Presence of a VFPv3 unit (inferred from above) with the 16 double registers (-d16, not -d32) as required by ARM AAPCS section 6 variant ("hardfp") - Intentionally standardizing on the 16 register minimum.
The only item up for (some) discussion seems to be use of Thumb2. Builds so far have been having problems when turning on T2. For various reasons, I'm not particularly desperate to see us build with T2. A todo of mine is to confirm that the GCC interworking trampolines mean it doesn't matter and we can make changes to have some T2 bits later (which is how I understand that this should be working, but I want to verify by spending some quality time with objdump and a few compiled libraries).
2). NEON is ARM's SIMD (answer to SSE/AltiVec/etc.). It shares registers with VFPv3 (not totally unlike other arch's implementations). It's not a part of the core ABI we are discussing. We have not discussed any specific NEON plans up to now, other than it might be nice sometime to have NEON optimized libraries and so forth.
Hope that helps!
Jon.
On Mon, Jun 6, 2011 at 2:35 PM, Jon Masters jcm@redhat.com wrote:
On Sun, 2011-06-05 at 09:54 +0100, Peter Robinson wrote: Right. v7 based Tegra parts will be supported by virtue of the vfpv3-d16 ABI (some newer VFPv3 parts have 16 additional optional registers not required by the minimal implementation we are basing upon in Fedora, intentionally, for ABI linkage, so that there's no break again).
Note that the VFPv3-D16, VFPv3-D32, and NEON are all ABI compatible. You can call -D32 code from -D16 and vice-versa.
-- Michael
On Sun, 2011-06-05 at 22:35 -0400, Jon Masters wrote:
The only item up for (some) discussion seems to be use of Thumb2. Builds so far have been having problems when turning on T2. For various reasons, I'm not particularly desperate to see us build with T2. A todo of mine is to confirm that the GCC interworking trampolines mean it doesn't matter and we can make changes to have some T2 bits later (which is how I understand that this should be working, but I want to verify by spending some quality time with objdump and a few compiled libraries).
For the record, after re-learning way too much about how the dynamic linker, GOT, PLT, etc. work, and going through a bunch of example objdumps so far...and then also discovering section 3.1.3.2 of the AAELF, I think I can answer the question with the following quotes:
1). "A PLT entry must be able to branch any distance to either instruction-set state. The span and state are fixed when the executable is linked dynamically. A PLT entry must therefore end with code similar to the following." (snip example using ip for linkage)
2). " ...it is generally pointless trying to construct a PLT entry entirely in 16-bit Thumb instructions. Even with the overhead of an inline Thumb-to-ARM state change, an ARM-state entry is usually smaller and always faster".
Which gels with the ARM-state PLTs I've seen generated from builds (even with Thumb2 enabled during build time). I still want to actually finish testing Thumb2 build libraries used with a non-Thumb application, but I think it's now reasonable to say we don't need to make the call on Thumb2, should just complete the v7 bringup without Thumb2 and then turn on Thumb2 later/fix up bugs we find it doing that at that point.
Please tell me if I am wildly off the mark on this technically.
Jon.
P.S. It seems that interworking is a requirement for Linux AAPCS built toolchains and will necessarily enable this as part of the build - am I wrong or are the GCC docs are out of date in this respect?
On Wed, 2011-06-08 at 03:53 -0400, Jon Masters wrote:
Which gels with the ARM-state PLTs I've seen generated from builds (even with Thumb2 enabled during build time). I still want to actually finish testing Thumb2 build libraries used with a non-Thumb application, but I think it's now reasonable to say we don't need to make the call on Thumb2, should just complete the v7 bringup without Thumb2 and then turn on Thumb2 later/fix up bugs we find it doing that at that point.
Please tell me if I am wildly off the mark on this technically.
I've had another ACK that this is correct. So let's not worry about Thumb2 for the moment. Let's get this working well with just ARM.
Jon.
On Wed, 2011-06-08 at 03:53 -0400, Jon Masters wrote:
P.S. It seems that interworking is a requirement for Linux AAPCS built toolchains and will necessarily enable this as part of the build - am I wrong or are the GCC docs are out of date in this respect?
Nick Clifton says he'll apply a patch to fix this.
Jon.
On 06/05/2011 02:10 AM, Chris Tyler wrote:
On Sat, 2011-06-04 at 20:53 -0400, Jon Masters wrote:
[0] We're making a "one time" incompatible ABI switch in F-15 bringup to the "hard float" ABI defined in section 6 of the ARM AAPCS (commonly referred to as the ARM EABI - but that doesn't actually exist as a name). The procedure call standard will be ARM AAPCS vfpv3-d16, as defined in section 6 of that document. Other distros are switching and this will form the basis of any LSB standardization effort later on. Think of v7 and v5 as being different arches, which they are really.
And to further clarify:
- This is an addition, not a switch -- the intention is to continue to
support armv5tel in addition to armv7hl at this time -- Tegra and Marvell Kirkwood (including plug computer) devices which do not support armv7hl will continue to work with armv5tel.
- The significant incompatibility is hardfp vs. softfp ABI (moreso than
v7 vs. v5).
So would it not be more sensible to make the distro ARMv7 without NEON? That was it would also work on the Tegra while still leaving the scope for having a handful of packages that benefit from NEON available? This would be similar to having the i386 distro with a few i686 packages (e.g. kernel, glibc) where beneficial. Since the ABI is the same I think this would be a better solution, especialy since Tegra is quite widely used and it is becoming a lot more common (AC100, TrimSlice, a number of new tablets, etc.).
Gordan
On Sun, Jun 5, 2011 at 12:18 PM, Gordan Bobic gordan@bobich.net wrote:
On 06/05/2011 02:10 AM, Chris Tyler wrote:
On Sat, 2011-06-04 at 20:53 -0400, Jon Masters wrote:
[0] We're making a "one time" incompatible ABI switch in F-15 bringup to the "hard float" ABI defined in section 6 of the ARM AAPCS (commonly referred to as the ARM EABI - but that doesn't actually exist as a name). The procedure call standard will be ARM AAPCS vfpv3-d16, as defined in section 6 of that document. Other distros are switching and this will form the basis of any LSB standardization effort later on. Think of v7 and v5 as being different arches, which they are really.
And to further clarify:
- This is an addition, not a switch -- the intention is to continue to
support armv5tel in addition to armv7hl at this time -- Tegra and Marvell Kirkwood (including plug computer) devices which do not support armv7hl will continue to work with armv5tel.
- The significant incompatibility is hardfp vs. softfp ABI (moreso than
v7 vs. v5).
So would it not be more sensible to make the distro ARMv7 without NEON?
There's no mention of NEON above. Where do you get that idea from?
Peter
On 06/05/2011 12:23 PM, Peter Robinson wrote:
On Sun, Jun 5, 2011 at 12:18 PM, Gordan Bobicgordan@bobich.net wrote:
On 06/05/2011 02:10 AM, Chris Tyler wrote:
On Sat, 2011-06-04 at 20:53 -0400, Jon Masters wrote:
[0] We're making a "one time" incompatible ABI switch in F-15 bringup to the "hard float" ABI defined in section 6 of the ARM AAPCS (commonly referred to as the ARM EABI - but that doesn't actually exist as a name). The procedure call standard will be ARM AAPCS vfpv3-d16, as defined in section 6 of that document. Other distros are switching and this will form the basis of any LSB standardization effort later on. Think of v7 and v5 as being different arches, which they are really.
And to further clarify:
- This is an addition, not a switch -- the intention is to continue to
support armv5tel in addition to armv7hl at this time -- Tegra and Marvell Kirkwood (including plug computer) devices which do not support armv7hl will continue to work with armv5tel.
- The significant incompatibility is hardfp vs. softfp ABI (moreso than
v7 vs. v5).
So would it not be more sensible to make the distro ARMv7 without NEON?
There's no mention of NEON above. Where do you get that idea from?
Chris said that Tegra wouldn't be supported on armv7hl but would continue to work on armv5tel. The only reason why Tegra wouldn't work with the armv7 port would be due to it's lack of NEON instructions, since it is an armv7 processor. It was implied rather than explicit.
Gordan
On Sunday, June 05, 2011 06:30:00 AM Gordan Bobic wrote:
On 06/05/2011 12:23 PM, Peter Robinson wrote:
On Sun, Jun 5, 2011 at 12:18 PM, Gordan Bobicgordan@bobich.net wrote:
On 06/05/2011 02:10 AM, Chris Tyler wrote:
On Sat, 2011-06-04 at 20:53 -0400, Jon Masters wrote:
[0] We're making a "one time" incompatible ABI switch in F-15 bringup to the "hard float" ABI defined in section 6 of the ARM AAPCS (commonly referred to as the ARM EABI - but that doesn't actually exist as a name). The procedure call standard will be ARM AAPCS vfpv3-d16, as defined in section 6 of that document. Other distros are switching and this will form the basis of any LSB standardization effort later on. Think of v7 and v5 as being different arches, which they are really.
And to further clarify:
- This is an addition, not a switch -- the intention is to continue to
support armv5tel in addition to armv7hl at this time -- Tegra and Marvell Kirkwood (including plug computer) devices which do not support armv7hl will continue to work with armv5tel.
- The significant incompatibility is hardfp vs. softfp ABI (moreso than
v7 vs. v5).
So would it not be more sensible to make the distro ARMv7 without NEON?
There's no mention of NEON above. Where do you get that idea from?
Chris said that Tegra wouldn't be supported on armv7hl but would continue to work on armv5tel. The only reason why Tegra wouldn't work with the armv7 port would be due to it's lack of NEON instructions, since it is an armv7 processor. It was implied rather than explicit.
the stuff i have built has been hardfp with thumb vfpv3-d16 and thumb. i setup things so you could have optional neon enabled builds. armv7hl and armv7nhl
Dennis
-
Chris Tyler -
Dennis Gilmore -
Derek Atkins -
Gordan Bobic -
Jon Masters -
Michael Hope -
Peter Robinson