Re: Questions regarding armhf port for Raspberry Pi
> If you identify the v7 instructions that are not in v6, you can use
> something like the attached, which I wrote to count the percentage of
> MaverickCrunch instructions in the binaries in a Debian package.
I can tell you the answer now.
If you're building in ARM mode there's approximately zero significant
differences. Most of the differences have negligible performance benefit (and
may even hurt performance). The same applies for ARMv6 v.s. ARMv5te.
Most of the differences are in the privileged system system architecture. i.e.
only the kenrel needs to care. I'd be amazed if ARM mode code for armv5te is
substantially different from ARMv7.
Tuning for a specific core can make a difference, but that's orthogonal the
the architecture revision, and applies equally to e.g. Cortex-A8 v.s. Cortex-
A9.
The only real reason to compile for ARMv7 is if you're using Thumb mode.
Thumb-2 (i.e. ARMv7) is in practice completely different to Thumb-1 (as
implemented by all relevant v5/v6 cores). Thumb-2 gives you approximately ARM
mode performance with smaller code, or alternatively Thumb-1 code size with
less sucky performance. Thumb-1 is only interesting if your primary goal is
code size, in which case you should also be using -Os rather than -O2.
The real benefit of armhf is hardware floating point (i.e. VFP). Using a full
hard-float ABI gives some additional benefit, with the Cortex-A8 having
particularly poor perormance characteristics in some fairly common cases. I'd
expect more conventional FPU implementations (i.e. arm9/arm11/Cortex-A9) to be
less sensitive to the ABI.
The assumption with armhf was that anyone making high performance hardware
will be using a vaguely modern core, and low-end hardware won't waste silicon
an on FPU. Surely noone's going to be dumb enough to use an arm11 in a new
design...
Paul
Reply to: