15

How to determine whether NEON engine exists on given ARM processor? Any status/flag register can be queried for such purpose?

hippietrail
  • 15,848
  • 18
  • 99
  • 158
Thomson
  • 20,586
  • 28
  • 90
  • 134
  • 1
    there are a ton of coprocessor registers that are there for that purpose to give you the gory details on what is supported in that core and what isnt. get the TRM for that or a similar core to see where these registers live. – old_timer Nov 02 '14 at 16:03
  • 2
    I believe that ARM processors are designed s.t. this information and those registers are actually privileged; Under Linux, therefore, you must look at `/proc/cpuinfo` to look for the NEON or Advanced SIMD flag. For privileged code, look at the ARMv7 Architecture Reference Manual, Section _B3.12.19 c1, Coprocessor Access Control Register (CPACR)_; Bit 31 of that register is what you want. – Iwillnotexist Idonotexist Nov 02 '14 at 16:06
  • Bit 31 of CPACR disables NEON instructions deocding when set to 1, which seems not a direct way to detect NEON engine. – Thomson Nov 02 '14 at 16:14
  • 1
    @Thomson Read immediately below; _On an implementation that:_ As well, the bit resets to zero if supported. – Iwillnotexist Idonotexist Nov 02 '14 at 16:15
  • @Iwillnotexist Idonotexist, your are right. It seems to be a good option. – Thomson Nov 02 '14 at 16:22
  • @Thomson Although on second thought I'm not entirely pleased with it now; For a processor that supports neither VFP nor NEON the bit is `UNK/SBZP`, which the glossary reports as Reads Unknown/Writes Should Be Zero or Preserve (I don't know why). And yet CPACR is the register that boot software must configure in order to enable CP10 and CP11, which are the Advanced SIMD coprocessors. – Iwillnotexist Idonotexist Nov 02 '14 at 16:32
  • Ah; I'm digging in _B5.3 Advanced SIMD and VFP feature identification registers_ now. – Iwillnotexist Idonotexist Nov 02 '14 at 16:40
  • Got it. See Linux's VFP initialization code here http://lxr.free-electrons.com/source/arch/arm/vfp/vfpmodule.c?v=2.6.31#L495; It examines the MVFR1 described in the ARM architecture reference manual Section _B5.3_, and if Advanced SIMD hardware supports all of a) Single-Precision Floating Point Operations b) Integer Operations and c) Load-Store Operations, then the HWCAP_NEON flag is set. – Iwillnotexist Idonotexist Nov 02 '14 at 17:18
  • 5
    Although the comment appears irrelevant to @Thomson's scenario, I will just keep doing my broken record thing and point out that parsing /proc/cpuinfo is _never_ the correct answer. HWCAPS is the way to determine CPU features from a Linux userland process. http://community.arm.com/groups/android-community/blog/2014/10/10/runtime-detection-of-cpu-features-on-an-armv8-a-cpu – unixsmurf Nov 02 '14 at 18:41
  • @unixsmurf, I have no idea if Mr or Ms Thomson has access to all the registers, but for most people looking for this type of info, they are just using Android/Linux/iOS or whatever and that is the correct answer. I will use your link. – Peter M Nov 14 '14 at 00:18
  • @PeterM: thanks for being less lazy than me :) – unixsmurf Nov 14 '14 at 10:08
  • @unixsmurf - `HWCAPS` does not scale. It only works for Linux and NEON, but not other platforms or other extensions like CRC32 and Crypto. What I found in practice is: determine compiler support with `__ARM_FEATURE_XXX`; and determine runtime support by trying an instruction with a `SIGILL` handler in place. The compile time/runtime strategy is the only thing I have found that works well across platforms and compilers. – jww May 17 '16 at 02:19
  • @jww: a little bit confused by the "does not scale" statement, given that CRC32 and Crypto are explicitly supported through the hwcaps strategy - albeit using `HWCAP2` for the 32-bit ARM architecture. – unixsmurf May 18 '16 at 08:08

4 Answers4

15

I believe unixsmurf's answer is about as good as you'll get if using an OS with privileged kernel. For general purpose feature detection, it seems ARM has made it a requirement to get this from the OS, and so you must use an OS API to get it.

  • On Android NDK use #include <cpu-features.h> with (android_getCpuFamily() == ANDROID_CPU_FAMILY_ARM) && (android_getCpuFeatures() & ANDROID_CPU_ARM_FEATURE_NEON). Note this is for 32 bit ARM. ARM 64 bit has different flags but the idea is the same. See the sources/docs.
  • On Linux, if available use #include <sys/auxv.h> and #include <asm/hwcap.h> with getauxval(AT_HWCAP) & HWCAP_NEON.
  • On iOS, I'm not sure there is a dynamic call, the methodology seems to be that you build your app targeting NEON, then make sure your app is flagged to require NEON so it will only install on devices which support it. Of course you should use the pre-defined preprocessor flag __ARM_NEON__ to make sure everything is in order at compile time.
  • On whatever Microsoft does or if you are using some other RTOS... I don't know...

Actually you'll see a lot of Android implementations which just parse /proc/cpuinfo in order to implement android_getCpuFeatures().... Heh. But still it seems to be getting improved and newest versions use the getauxval method.

Peter M
  • 1,918
  • 16
  • 24
  • 2
    All iOS hardware supported by iOS 5 and later have NEON; you can simply assume that NEON is present, there's no need for any check (but you could check dynamically using `sysctl` if you really wanted to). – Stephen Canon Nov 14 '14 at 22:43
  • 2
    On Android NDK check if (android_getCpuFamily() == ANDROID_CPU_FAMILY_ARM && (android_getCpuFeatures() & ANDROID_CPU_ARM_FEATURE_NEON) != 0) – VMMF Aug 24 '16 at 02:22
  • Thanks, yeah, I updated.... obviously more complicated now with ARM64 etc. – Peter M Aug 24 '16 at 16:35
  • I *think* `getauxval(AT_HWCAP) & HWCAP_NEON` works for Aarch64, but not Aarch32. I believe there's other defines you need to check. – jww Jul 25 '17 at 03:47
  • `HWCAP_NEON` is for [Aarch32](http://elixir.free-electrons.com/linux/latest/source/arch/arm/include/uapi/asm/hwcap.h), and `HWCAP_ASIMD` is for [Aarch64](http://elixir.free-electrons.com/linux/latest/source/arch/arm64/include/uapi/asm/hwcap.h) – watertavi Sep 14 '17 at 15:52
  • 1
    The unixsmurf link is down, but it looks like there's an archived copy here: https://web.archive.org/web/20160629111439/https://community.arm.com/groups/android-community/blog/2014/10/10/runtime-detection-of-cpu-features-on-an-armv8-a-cpu – Jack O'Connor Oct 01 '19 at 14:40
1

One reliable way is to check the architectural feature trap register. For example, on ARM Cortex A35, you can check the value of HCPTR register to see whether NEON is implemented (0x000033FF), or not (0x0000BFFF). The register name and indication value are platform dependent, making sure to check the technical reference manual.

Tao
  • 11
  • 1
0

Is there anyway to check if Neon and sve is supported? I have seen someone saying something about the HCPTR register, but it does not seem to have any relationship to neon and besides looks to be a Aarch32 instruction according to the docs https://developer.arm.com/docs/ddi0595/g/aarch32-system-registers/hcptr

MustSee
  • 121
  • 2
  • 7
0

If /proc/config.gz is present, you can test for NEON support in the kernel using the command:

zcat /proc/config.gz | grep NEON

If the NEON unit is present, the command outputs:

CONFIG_NEON=y

To ensure that the processor supports the NEON extension, you can issue the command:

cat /proc/cpuinfo | grep neon

If it supports the NEON extension, the output shows neon, for example:

# cat /proc/cpuinfo | grep neon
Features        : half thumb fastmult vfp edsp thumbee neon vfpv3 tls vfpv4 idiva idivt vfpd32 lpae evtstrm 
Features        : half thumb fastmult vfp edsp thumbee neon vfpv3 tls vfpv4 idiva idivt vfpd32 lpae evtstrm

see Learn the architecture - Neon programmers' guide

kgbook
  • 388
  • 4
  • 16