On Sun, Jun 5, 2011 at 12:22 PM, Gordan Bobic <gordan@xxxxxxxxxx> wrote: > On 06/05/2011 09:54 AM, Peter Robinson wrote: >> On Sun, Jun 5, 2011 at 2:10 AM, Chris Tyler<chris@xxxxxxxxxxx> 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@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
