Extensions that introduce new architectural state require special OS support, because the OS has to save/restore restore more data on context switches. So from the OSes perspective, there's nothing extra it needs to do to let user-space code run SSSE3 instructions, if the OS supports SSE.
SSE, AVX, and AVX512 are the extensions that introduced new architectural state.
- SSE introduced the xmm regs (and MXCSR for rounding modes and FP exception state)
- AVX introduced ymm (the lower half of which are the old xmm regs).
- AVX512 introduced zmm (extending the ymm regs), and also doubled the number of vector regs in 64bit mode: zmm0-zmm31.
You check for CPU support for SSE or AVX the usual way, with the CPUID instruction.
To prevent silent data corruption when using a new extension on a multi-tasking OS that doesn't save/restore the new architectural state on context switches, SSE instructions fault as illegal instructions if the OS hasn't set an OS-support bit in a control register. So vector extensions "don't work" on OSes that don't know about saving/restoring the necessary state for that extension.
For SSE, there may not be any clean OS-independent way to detect that the OS has promised to save/restore SSE state on context switches by setting the CR4.OSFXSR, CR4.OSXMMEXCPT etc. bits, because even reading a control register is privileged, and there's no CPUID bit that reflects the setting. On Windows, you can use GetEnabledXStateFeatures to check that the OS knows how to save/restore the vector register state. I'm not sure what you need on other OSes; SSE support is so widespread that you'd have to be using a really ancient version (or homebrew) OS for this to be a problem.
For AVX, we don't need OS support to detect that AVX is usable (supported by hardware and enabled by the OS): CPUID includes an OSXSAVE feature bit that will be set when the OS has enabled AVX.
From Intel's intro to AVX:
- Verify that the operating system supports XGETBV using
CPUID.1:ECX.OSXSAVE bit 27 = 1.
- At the same time, verify that
CPUID.1:ECX bit 28=1 (Intel AVX supported) and/or bit 25=1 (AES
supported) ... (and other bits for FMA, AES, and PCLMULQDQ)
- Issue
XGETBV, and verify that the feature-enabled mask
at bits 1 and 2 are 11b (XMM state and YMM state enabled by the
operating system).
It may be easier to call an OS-provided function to detect OS support, instead of using inline asm or a feature-detect library to do all this.
The same is true for AVX512: you can check the CPUID feature bit for the instruction set, and check that the OS has promised to manage the new architectural state on context switches by enabling the right bits in with XSETBV. (So you should check with XGETBV).
