x86 opcode/CPUID/MSR allocations

[Christian Ludloff]

If x86 opcode/CPUID/MSR allocations are not
of your concern, then you can stop reading.

-------------------- 8< -------------------

I was asked to relay this to binutils/LKML.

As of 2025, the following are in active use
by a corporate entity other than Intel/AMD.

Any collisions with them should be avoided.

- opcode 0Eh in PM64 - x86 PUSH CS that got
  removed by x86-64 in 2002; not used since

- opcode 0Fh,36h and opcode 0Fh,3Eh - there
  is a historic collision with Cyrix RDSHR,
  but that is not considered to be an issue

- opcode 0Fh,3Ah,E0h...EFh in classic, VEX,
  EVEX, Map3, and Map7 encodings, without a
  prefix, or CS/SS/DS/ES/FS/GS, LOCK, REPE/
  REPNE, or ASIZE/OSIZE/REX (but not REX2!)
  prefixes - a historic collision with K10M
  VCVTFXPNTPD2DQ (at MVEX opcode E6h prefix
  F2) exists but is not considered an issue

- opcode 0Fh,1Eh,/0 - a "hinting NOP" group

- CPUID range E000_xxxxh - unspecified leaf
  return values at this particular time

- MSR range E000_xxxxh - unspecified values
  after RESET - unchanged values after INIT

I have documented them at www.sandpile.org.

-------------------- 8< -------------------

--
C.