[fedora-arm] [Fwd: Activity Day June 10th - ARMv7 F15 hardfp bringup]

[Jon Masters]

On Sun, 2011-06-05 at 09:54 +0100, Peter Robinson wrote:
> On Sun, Jun 5, 2011 at 2:10 AM, Chris Tyler <chris at 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.