The memory operand version tends to be as slow or slower than the manual implementation, so LLVM is right to avoid it.
This is indeed a thing. I believe in general instructions are executed slower when there are more than 4 legacy prefixes. And there are plenty of other timing differences between different microarchitectures
It must be the rightmost prefix among the prefixes. It also can't be repeated, unlike all other prefixes
> Some instructions require VEX.L or VEX.W to be 0 or 1, and some encodings result in completely different instructions if you change VEX.L. There is even an instruction where AMD got this wrong! VPERMQ requires…
This flowchart hides the most awful parts (IMO) of x86 prefixes: some combinations of prefixes are invalid but still parsed and executed, like combining two segment overrides, or placing a legacy prefix after a REX…
> However, in this case it doesn’t matter; those top bits are discarded when the result is written to the 32-bit eax. Fun (but useless) fact: This being x86, of course there are at least three different ways [1] to…
Evaluating how much of instruction space we cover was indeed difficult. Initially, we wanted to parse Intel XED's datafiles to generate a map of valid instruction space, but we ended up going for the simpler approach of…
Not a dumb question at all! Documentation is definitely not one of x86's strengths. Other architectures do much better. For example, ARM provides formal models of their CPUs, and RISC-V is so simple you could implement…
Hi! I'm one of the authors. Cool to see our work show up on HN! I'm happy to answer questions if there are any.
The memory operand version tends to be as slow or slower than the manual implementation, so LLVM is right to avoid it.
This is indeed a thing. I believe in general instructions are executed slower when there are more than 4 legacy prefixes. And there are plenty of other timing differences between different microarchitectures
It must be the rightmost prefix among the prefixes. It also can't be repeated, unlike all other prefixes
> Some instructions require VEX.L or VEX.W to be 0 or 1, and some encodings result in completely different instructions if you change VEX.L. There is even an instruction where AMD got this wrong! VPERMQ requires…
This flowchart hides the most awful parts (IMO) of x86 prefixes: some combinations of prefixes are invalid but still parsed and executed, like combining two segment overrides, or placing a legacy prefix after a REX…
> However, in this case it doesn’t matter; those top bits are discarded when the result is written to the 32-bit eax. Fun (but useless) fact: This being x86, of course there are at least three different ways [1] to…
Evaluating how much of instruction space we cover was indeed difficult. Initially, we wanted to parse Intel XED's datafiles to generate a map of valid instruction space, but we ended up going for the simpler approach of…
Not a dumb question at all! Documentation is definitely not one of x86's strengths. Other architectures do much better. For example, ARM provides formal models of their CPUs, and RISC-V is so simple you could implement…
Hi! I'm one of the authors. Cool to see our work show up on HN! I'm happy to answer questions if there are any.