Re: [fedora-arm] [Fwd: Activity Day June 10th - ARMv7 F15 hardfp bringup]
On Sun, Jun 5, 2011 at 2:10 AM, Chris Tyler ch...@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 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [fedora-arm] [Fwd: Activity Day June 10th - ARMv7 F15 hardfp bringup]
On Sun, Jun 5, 2011 at 12:18 PM, Gordan Bobic gor...@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 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [fedora-arm] [Fwd: Activity Day June 10th - ARMv7 F15 hardfp bringup]
On Sun, Jun 5, 2011 at 12:22 PM, Gordan Bobic gor...@bobich.net wrote: On 06/05/2011 09:54 AM, Peter Robinson wrote: On Sun, Jun 5, 2011 at 2:10 AM, Chris Tylerch...@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 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [fedora-arm] [Fwd: Activity Day June 10th - ARMv7 F15 hardfp bringup]
On Sun, 2011-06-05 at 09:54 +0100, Peter Robinson wrote: On Sun, Jun 5, 2011 at 2:10 AM, Chris Tyler ch...@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. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
