jxors

6 ms·

1.
by jxors 7mo ago
The memory operand version tends to be as slow or slower than the manual implementation, so LLVM is right to avoid it.
2.
by jxors 8mo ago
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
3.
by jxors 8mo ago
It must be the rightmost prefix among the prefixes. It also can't be repeated, unlike all other prefixes
4.
by jxors 8mo ago
> 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 VEX.W=1, but some AMD CPU
5.
by jxors 8mo ago
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 prefix. The CPU also does
6.
by jxors 10mo ago
> 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 encode this instructio
7.
by jxors 2y ago
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 computing cover
8.
by jxors 2y ago
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 all its semantic
9.
by jxors 2y ago
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.