3 ms·
So it sounds like (among other things) they're adding 3-address integer instructions to an instruction encoding only used for vector instructions today. I was
by KerrAvon 3y ago
So it sounds like (among other things) they're adding 3-address integer instructions to an instruction encoding only used for vector instructions today.
I was not familiar with the AVX vector instructions at this level of detail.
https://en.wikipedia.org/wiki/EVEX_prefix https://en.wikipedia.org/wiki/EVEX_prefix
- peterfirefly 3y agoHave you noticed that some of the bits in the EVEX prefix (after the 62h) byte are inverted? That's because it hides inside the BOUND instruction in a way that allows it to be used outside of 64-bit mode code. The BOUND instruction never existed in 64-bit mode, so Intel was free to do whatever they wanted with the 62h opcode, but they thought it would be enable EVEX in 16/32-bit code too. The BOUND instruction must take a memory operand -- so the MOD bits can never be 11b (which would specify a register operand). The MOD bits are the upper two bits of the modrm byte (the byte right after the 62h opcode). So, if we don't allow the "upper" registers in 32-bit mode and only the "lower" 8 registers AND if we invert bit 3 of their register numbers and put those extra register specifier bits in bit 7/6/5 of the byte after the 62h opcode THEN we can fit EVEX into 32-bit mode, because those bits will always be 111b in 32-bit mode! So outside of 64-bit mode, if we have a 62h opcode with a modrm byte with MOD!=11b: it's a BOUND instruction. If MOD=11b: it's an EVEX prefix.