The correct way for MacOS users to check for CPU instruction sets

[Artoria2e5]

The current README has this to say about determining the SIMD build mode on Macs:

Mac OS X has no /proc/cpuinfo file, so Mac users will need to [Apple Icon] → About This Mac, then compare the processor type displayed in the resulting dialog box against the following Wikipedia entries:

This actually does not work at all since Apple now only tells you it's a "6-core Intel i7 CPU". The correct way to do it, which does not involve wikipedia, is by querying
one of the following on the terminal:

$ sysctl hw.optional
hw.optional.floatingpoint: 1
hw.optional.mmx: 1
hw.optional.sse: 1
hw.optional.sse2: 1
hw.optional.sse3: 1
hw.optional.supplementalsse3: 1
hw.optional.sse4_1: 1
hw.optional.sse4_2: 1
hw.optional.x86_64: 1
hw.optional.aes: 1
hw.optional.avx1_0: 1
hw.optional.rdrand: 1
hw.optional.f16c: 1
hw.optional.enfstrg: 1
hw.optional.fma: 1
hw.optional.avx2_0: 1
hw.optional.bmi1: 1
hw.optional.bmi2: 1
hw.optional.rtm: 0
hw.optional.hle: 0
hw.optional.adx: 1
hw.optional.mpx: 0
hw.optional.sgx: 0
hw.optional.avx512f: 0
hw.optional.avx512cd: 0
hw.optional.avx512dq: 0
hw.optional.avx512bw: 0
hw.optional.avx512vl: 0
hw.optional.avx512ifma: 0
hw.optional.avx512vbmi: 0
$ sysctl machdep.cpu.features
FPU VME DE PSE TSC MSR PAE MCE CX8 APIC SEP MTRR PGE MCA CMOV PAT PSE36 CLFSH DS ACPI MMX FXSR SSE SSE2 SS HTT TM PBE SSE3 PCLMULQDQ DTES64 MON DSCPL VMX SMX EST TM2 SSSE3 FMA CX16 TPR PDCM SSE4.1 SSE4.2 x2APIC MOVBE POPCNT AES PCID XSAVE OSXSAVE SEGLIM64 TSCTMR AVX1.0 RDRAND F16C

As I understand, the former is the BSD way of describing stuff, while the latter is specific to Mac OS/Darwin.

Please update the README.

[retina]

IMO the only true-and-correct^TM method of finding out what one's system can execute is to simply execute an instruction from the set. If you get an exception then you can't use that set.

This it because it isn't just the CPU you are testing for, it is also the OS. If the OS doesn't enable, and support the instruction set you want to use, even if the CPU has it, then you won't be able to execute them. If you get no exception thrown then you are good to go.

And it generalises to all OSes and systems out there. No need to find special files and parse text outputs and whatnot.

[rogue]

Originally Posted by retina

IMO the only true-and-correct^TM method of finding out what one's system can execute is to simply execute an instruction from the set. If you get an exception then you can't use that set.

This it because it isn't just the CPU you are testing for, it is also the OS. If the OS doesn't enable, and support the instruction set you want to use, even if the CPU has it, then you won't be able to execute them. If you get no exception thrown then you are good to go.

And it generalises to all OSes and systems out there. No need to find special files and parse text outputs and whatnot.

If you want to check programatically, you can use __builtin_cpu_supports() in C/C++. Write a small command line program that checks for each feature you care about.

[xilman]

Originally Posted by retina

IMO the only true-and-correct^TM method of finding out what one's system can execute is to simply execute an instruction from the set. If you get an exception then you can't use that set.

This it because it isn't just the CPU you are testing for, it is also the OS. If the OS doesn't enable, and support the instruction set you want to use, even if the CPU has it, then you won't be able to execute them. If you get no exception thrown then you are good to go.

And it generalises to all OSes and systems out there. No need to find special files and parse text outputs and whatnot.

I am curious.

Can you give a specific example of an instruction which is supported by the bare metal but which can not be executed because of a restriction imposed by the overlying OS?

This is a genuine question because I have never come across an example before.

[retina]

Originally Posted by xilman

I am curious.

Can you give a specific example of an instruction which is supported by the bare metal but which can not be executed because of a restriction imposed by the overlying OS?

This is a genuine question because I have never come across an example before.

There are many.

The AVX instructions that use ZMM registers, for example, must be enabled by the OS before anyone can use them. I believe this is because the FXSAVE/FXRESTORE type instructions have a different format for the extra registers. So if the OS is unaware of how, or unwilling, to enable such instructions, then the applications also can't use them.

[xilman]

Originally Posted by retina

There are many.

The AVX instructions that use ZMM registers, for example, must be enabled by the OS before anyone can use them. I believe this is because the FXSAVE/FXRESTORE type instructions have a different format for the extra registers. So if the OS is unaware of how, or unwilling, to enable such instructions, then the applications also can't use them.

So what happens if I hand-craft an executable file which contains such an instruction and then try to execute it?

[retina]

Originally Posted by xilman

So what happens if I hand-craft an executable file which contains such an instruction and then try to execute it?

If the instruction is not supported then you get an exception. You can test it with an older OS not aware of AVX and try executing some AVX instructions on a newer CPU.

[ewmayer]

Originally Posted by Artoria2e5

The current README has this to say about determining the SIMD build mode on Macs:

This actually does not work at all since Apple now only tells you it's a "6-core Intel i7 CPU". The correct way to do it, which does not involve wikipedia, is by querying one of the following on the terminal:

$ sysctl hw.optional
[snip]

A good suggestion, thanks. The README has been updated.

Originally Posted by retina

IMO the only true-and-correct^TM method of finding out what one's system can execute is to simply execute an instruction from the set. If you get an exception then you can't use that set.

This it because it isn't just the CPU you are testing for, it is also the OS.

...and the compiler and assembler one is using under said OS. IIRC when George was first beginning to play with the then-new avx-512 instruction set, he found that MASM had no support for it. I had no such trouble with the latest stable version of gcc/as under Linux of the "GIMPS KNL", but found that the accompanying version of gdb did not properly support display of the avx-512 registers, so we needed to go to a newer unstable-branch gdb.

Anyhow, the OP-post stuff is all about quickly getting a builder/user to "which instructions should be supported on my CPU?", building with the associated inline-asm selected, then seeing if the resulting binary runs properly.