Indeed, and this is where the usenet post linked in a sibling comment is really informative: In my opinion, the most common reasonable reason for including

Indeed, and this is where the usenet post linked in a sibling comment is really informative: In my opinion, the most common reasonable reason for including some instructions is: a) There is a datatype deemed worth supporting, i.e., whose use burns an interesting number of cycles, either because: 1) It gets used often enough, OR 2) It is used less often, but is really expensive. b) There is a reasonable hardware cost to support the datatype. c) Simulating the use of the datatype with the existing instructions is noticably expensive. In practice, b)+c) usually mean that the datatype operations can obtain useful parallelism in hardware, that cannot be gotten at by sequences of the existing instructions. IF it is difficult to beat sequences of existing instructions in speed, then only if those sequences are really frequent would one add new instrucions, i.e.e., for code density. Adding a little adder and shifter to the memory access unit meets all these conditions -- it's an operation that is effectively free in hardware, but would cost extra cycles & bytes to implement in software. So the "problem" with x86 isn't that such a complex addressing mode exists. It's that the ADD instruction has such a complex addressing mode, as does nearly every other instruction in the ISA. An 'ADD mem, reg' instruction is really a load, an add, and a store, and there's no hardware magic you can do to accelerate that -- it's just as fast to write "load, add, store" in software, so this fails tests b) and c). A RISC will typically have, let's say a dozen load/store instructions to support a variety of addressing modes (probably more if you account for atomics and vectors and non-temporals and whatnot). Then you only need one ADD instruction, one SUB instruction, one XOR instruction, maybe one FJCVTZS instruction, etc. But on x86, you get sort of a combinatoric explosion between possible combinations of instructions, addressing modes, and prefix bytes, which means your decoder has to support a dozen ADDs, a dozen SUBs, a dozen XORs, a dozen FJCVTZSes, and whatever.