Why is 1's complement still used for encoding vector instructions?

Question

In an answer, jww points out that 1's complement is still used in encoding vector instructions on intel architectures, and Ruslan clarifies that these instructions are being used more as auto-vectorization becomes common.

Is there an advantage of 1's complement that causes it to continue to be used in these instructions, or is it simply being used for historical reasons?

Quoting jww:

From Intel® 64 and IA-32 Architectures Software Developer’s Manual 2A, page 3-8:

3.1.1.8 Description Section

Each instruction is then described by number of information sections. The “Description” section describes the purpose of the instructions and required operands in more detail.

Summary of terms that may be used in the description section:
* Legacy SSE: Refers to SSE, SSE2, SSE3, SSSE3, SSE4, AESNI, PCLMULQDQ and any future instruction sets referencing XMM registers and encoded without a VEX prefix.
* VEX.vvvv. The VEX bitfield specifying a source or destination register (in 1’s complement form).
* rm_field: shorthand for the ModR/M r/m field and any REX.B
* reg_field: shorthand for the ModR/M reg field and any REX.R

Raddy

Answer 1

That article isn't talking about 1's complement being used for integer storage. Even VEX-encoded integer instructions are going to act on 2's compliment integers.

All that 1's compliment is saying there is that an encoded register ID in a VEX instruction needs to have the normal bits used to ID the register flipped. Some in that question speculated this was to prevent clashes with existing instructions which makes plenty of sense to me.

Villanueva

So they are really just saying they are flipping all the bits (bitwise negation) and that's all? – Raddy

@JosiahYoder - Yes, and only for the portion of the VEX-encoded instruction that identifies the registers the instruction acts on. The data it acts on that is stored in those registers (assuming an integer instruction) is still 2's compliment. – Villanueva

It's not speculation; the reason some bits in VEX prefixes are inverted is to make sure no valid 32-bit mode instruction will decode as a VEX prefix. VEX prefixes almost overlap with the encoding of some 32-bit mode instruction, so this was necessary to keep backwards compat of code that didn't previously #UD, allowing unambiguous decoding. – Snowden