[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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-

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 


Reply to: