Every other page in this course reports numbers. This one reports, in most places, that a number could not be taken — and that turns out to be the most useful thing on it, because knowing which claims about a feature you cannot run are still safe to repeat is a skill, and it is not the same skill as knowing the feature.
The evidence is eight bits long and they are all zero:
$ ./vecdump | sed -n '/AVX512F/,/hi16_zmm 0/p'
CPUID.7.0:EBX AVX512F 0 DQ 0 CD 0 BW 0 VL 0
XCR0 0x0000000000000207 (1 x87, 2 SSE, 5 opmask, 6 zmm_hi256, 7 hi16_zmm)
XCR0 opmask 0 zmm_hi256 0 hi16_zmm 0
Five feature bits and three state bits, and every one of them is zero. So this concept is reference plus a decoder, and the decoder is the interesting part: it works on bytes, and bytes do not need a processor to run on. The distinction is worth stating precisely, because the two are confused constantly:
Every AVX-512 instruction starts with the two bytes 62 and an eleven-bit field layout. Here is the field table, and every row is a thing the VEX prefix could not express at all:
Two rows of that table carry the whole design, and both are about space rather than about arithmetic.
The mandatory 1 in bit 2 is what makes the 62 opcode safe. In 32-bit mode, 0x62 is the BOUND instruction, which takes a ModRM byte — and the four bits of an EVEX prefix are precisely the bits that would have been a ModRM byte. Because one of them is required to be 1 and BOUND's ModRM byte is 16 bits wide, the two encodings can never be confused: a 32-bit program that decodes 62 as BOUND cannot reach a valid EVEX prefix, and a 64-bit program never sees BOUND at all. The extension bought 16 more registers by using the one opcode whose old meaning it could safely steal, and it made the theft safe by putting a constant in the stolen instruction's own ModRM byte.
The L'L pair is the second, and it is a genuine trap for anyone writing a decoder:
$ ./vecdump | sed -n '/THE FOUR LEVELS/,/no L at all/p'
THE FOUR LEVELS, and the L'L PAIR is the whole of it:
L'L = 00 no vector length in this instruction
L'L = 10 128 bit, xmm
L'L = 11 512 bit, zmm
and when L'L is 00 the SAME two bits are the ROUNDING CONTROL,
so a decoder cannot read them as a length without first
asking whether the instruction has a length. That is why the
round trip above has a row with b=1 and no L at all.
Those are four levels, and the two bits that select among them mean something else entirely when a particular bit elsewhere in the prefix is set. A decoder that reads L'L as a length without first asking whether the instruction has a length will decode a correct instruction into a wrong one — legal bytes, different instruction, no trap. That is the same class of bug as the one the previous course's encoder had, and it is why the last concept of this course round-trips its bytes against objdump rather than against a decoder it wrote.
And the mask registers, which have no analogue anywhere else in the instruction set. k0–k7 are not vector registers and not general registers: each is 64 bits, and each bit says whether one lane of the destination takes part. An AVX-512 add can be predicated on a mask for free — no compare instruction, no branch, no second pass over the data — because the mask is an operand of the arithmetic rather than an input to a sequence of it. Note the z bit in the field table, which is what makes the mask-off lanes either keep their old contents or become zero: a mask alone does not say what happens to the lanes it excludes, and that is a real omission a decoder has to handle.
Every claim on this page, sorted:
$ ./vecdump | sed -n '/WHAT IS QUOTED HERE/,/naming\./p'
QUOTED that a ZMM is 512 bits, that k0-k7 are 64 bits, that
z is merging-versus-zeroing, that b is broadcast
QUOTED the four-level hierarchy and its dispatch penalty
MEASURED the five CPUID bits are zero
MEASURED the XCR0 state bits are zero
MEASURED the encoder emits the bytes the SDM says and
objdump reads them back the same way
NOT MEASURED that any of it is FASTER
Six quoted claims, three measured ones, and one absence stated as an absence. The three measured claims are all about absence or about bytes, which is the only kind of claim this machine can support, and saying so is the whole discipline.
Now the XCR0 row, which is subtler than a feature bit and worth its own paragraph. CPUID reports what the silicon has. XCR0 is a list of what the OS has agreed to save and restore, and they are not the same thing: a machine can have the first without the second. This one does not have the first. But the two are worth separating anyway, because the way AVX-512 actually fails is the second way — an EVEX-encoded instruction whose own state bit is clear does not run slowly, it does not run at all, and it raises #UD, which the kernel turns into SIGILL rather than SIGSEGV. That is a different failure from the #GP in the first concept, and a program that only handles SIGSEGV will not catch it.
The artifact reads XCR0 with XGETBV and, in passing, makes an inference worth copying. A direct mov %cr4, %rax to read the gate that guards XGETBVfaults on this machine, so the bit is not read. It is inferred: XGETBV is #UD without CR4.OSXSAVE, and XGETBV returns, so the bit is set. A probe that answers the question by using the thing in the question beats a probe that reads a bit it is not allowed to read, and it costs one instruction instead of a fault.
They are the reasons the extension exists, and both are consequences of the mask register being an operand:
vbroadcastsd ymm0, [rbx] loads one eight-byte value into all four lanes. Those exact bytes are in the encoder's table in the last concept, encoded and decoded, and the dispatch is a field of the instruction rather than a separate load followed by a shuffle.Both of those are quoted, and both are the kind of claim that is easy to accept and hard to verify. The tail claim is checkable on a machine with AVX-512 by timing a 66-element loop against a 64-element one, and the interesting part is not the speed — it is whether the compiler generated one path or two, which is a disassembly question rather than a timing question, and which is answerable on any machine that has the compiler even if it has no AVX-512.
Most reference material about a feature you cannot run is written in the present tense — “AVX-512 executes masked operations in a single pass” — and the present tense is doing work it has not earned. Here is a way to write the same sentences so a reader knows exactly which of them to repeat:
THE THREE VERBS, and they are not
interchangeable.
QUOTED from a specification, and
checkable against the spec but
not against hardware you lack.
MEASURED on THIS machine, and
reproduced by a program that
ships with the course.
INFERRED a mechanism attached to a
duration, with no counter
behind it. The most dangerous
of the three, because it reads
like the other two.
Apply that to the three claims most often made about AVX-512 on a machine that has none. “The k mask removes the scalar tail” — QUOTED, and it is a claim about code shape that you can partly check by disassembly. “512-bit operations are faster than 256-bit” — NOT MEASURED HERE, and on most parts it is false because a wide vector triggers a frequency drop. “The dispatch penalty is a few cycles” — QUOTED, from the vendor manual, and a number a manual prints for a microarchitecture is a fact about that microarchitecture.
None of that makes the claims unusable. It makes them attributable, which is a different and more durable property: you can repeat a quoted claim, you can repeat a measured one with a program, and you must repeat an inferred one by saying whose inference it is. The habit worth taking from a feature you cannot run is not the feature. It is refusing to write a specification sentence in the present tense.
cd courses/x86simd/assets/samples && ./build_samples.sh, then read section 6B. (Expect three 0x62 rows in the encoder's table to round-trip and to be cross-checked against objdump with no hardware involved. This is the one exercise on this page you can actually complete, and it is the reason the course has a decoder at all.)L'L bug on purpose. Take the decoder in the last concept and remove the test for whether the instruction has a length, so L'L is always read as a length. (Expect the b=1 row to decode as a 512-bit instruction and objdump to disagree on exactly that row. It is the cleanest demonstration in the course of why a second reader matters: the round trip will still pass, because the encoder and the decoder now share the same wrong assumption, and that is the whole content of retraction 9.)#UD hypothesis without AVX-512. Find a kernel old enough not to enable the state bits on a machine that has them. (Expect an SIGILL rather than a SIGSEGV, and expect this to be the mechanism behind a class of bug reports that say “crashes on the new server, fine on the old one” with no further detail. The feature is present in the silicon and absent in the kernel’s promise, and the difference between the two is exactly one bit in one register that the failing process cannot read.)-mavx512f and disassemble. (Expect a masked final iteration rather than a scalar one, and expect it to be one of the few places where reading the disassembly teaches you something no amount of running the program will. The tail is a code shape, and code shape is the one property of a vectoriser that is directly observable from the outside.)Backwards, the previous concept measured the two things VEX changed, and this one is the same exercise at a width that cannot be run. The L'L pair is a direct descendant of the operand-map problem the assembly course's map concept found and fixed: the encoding has a field whose meaning depends on another field, and a decoder that ignores the dependency produces a legal instruction that is not the one intended.
Forwards, and this is the hinge of the course. Everything from here on is about two cores at once, and the connection is not thematic but mechanical: the SMP course measured that a data race costs a great deal and named the store buffer as the mechanism, and the next two concepts give the x86-64 instructions that address it. What this page contributes is a boundary: it is the one place in the collection where a whole feature's claims are demoted, and knowing that a demoted claim is still a claim you may repeat with attribution is the transferable part.
Outward. The 62 prefix is a beautiful piece of backward-compatible design — stealing an opcode and making the theft provably safe with a constant bit — and it is the same technique the 32-bit BOUND instruction was stolen from. A reader who wants the wider pattern should look at how VEX stole 0f space in the first place, which is in the VEX concept, and at how the ordering course uses the same table of opcodes to reason about fences. Both are the same lesson at different scales: an encoding is a namespace, and every extension is a negotiation with the decoder.