> 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 -- To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201203282033.23319.p...@codesourcery.com