Hacker News Reader

Comment by aengelke | Hacker News Reader

> But you will not find multiple different CPUs that decode valid instructions differently. If I run your weird old x86 code, either it will run correctly or it will fault.

Oh, that's not completely true. Intel 64 and AMD64 are not identical and they certainly have encodings that behave differently. As an example: f3 41 90 is pause on Intel, but xchg r8d, eax on AMD (granted, this is not a canonical instruction encoding). 66 e9 xx xx yy yy is a unconditional jump to a 32-bit relative offset on Intel, but on AMD, the offset is 16-bit only (yy yy are the start of the next instruction). x86-64 is typically used to refer to the very large common subset, but this doesn't mean the implementations behave identically.

There are also some weird corner cases where CPUs aren't 100% backwards compatible, just backwards compatible enough for the software that matters.

View on HN

For those less familiar with x86, the example instruction encodings that are interpreted differently on Intel and AMD are not base encodings, but instruction encodings modified with prefixes.

The x86 ISA includes a great number of bytes that are used as instruction prefixes, many of which are obsolete. The problem is that the effect of prefixes upon instructions has never been completely defined in any Intel or AMD documentation. The prefix effects have been documented for some instructions, but they were left unspecified for most other instructions.

This has lead to divergent implementations in the unspecified cases. Well-behaved compilers should not generate such undocumented combinations of instruction prefixes with base encodings.

> The problem is that the effect of prefixes upon instructions has never been completely defined in any Intel or AMD documentation.

In case of the jump example, the effects are documented by Intel and AMD and they still differ. Point of the GP was that all CPUs don't decode valid instructions differently, which is not fully accurate as shown by the examples; and some of these differences are also explicitly documented.

It's also not accurate that most prefixes are obsolete when most see regular use today (66 size override for 16-bit operations, f2/f3 for string operations, 66/f2/f3 mandatory prefix for many (e.g. SSE) instructions, 64/65 fs/gs override for thread-local storage access and per-thread kernel storage, f0 lock for atomic operations, 3e (again) for branch-taken hint, 4x REX prefix for r8-r15 and 64-bit operand size; one can argue that the 67 address-size override is useless, and only the 26, 2e, and 36 are ignored; I don't count VEX/EVEX/REX2 as prefixes but more as opcode escapes).

Pretty sure 3DNow's instruction space has been repurposed too. There are a few like that, or worse extremely similar but ever so slightly different between vendors or even generations of the same vendor. I won't claim to be an expert, this is all in IIRC territory for me.

No, the 0f 0f opcode (most of 3DNow was encoding-wise a single RMI-encoded opcode where the immediate specified the operation) and the 0f 0e opcode (FEMMS) were not repurposed by either Intel or AMD.

Good to know, thank you

Fair point.

66 E9 is not a practical compatibility problem, though: it’s not a useful encoding of a useful instruction on any CPU :)

Reply on news.ycombinator.com