52 ms·

Honestly, x86 is not nearly as CISC as those go. It just has a somewhat developed addressing modes comparing to the utterly anemic "register plus constant offse

by Joker_vD 11mo ago

Honestly, x86 is not nearly as CISC as those go. It just has a somewhat developed addressing modes comparing to the utterly anemic "register plus constant offset" one, and you are allowed to fold some load-arithmetic-store combinations into a single instruction. But that's it, no double- or triple-indexing or anything like what VAXen had. BINOP disp(rd1+rd2 shl #N), rs vs. SHL rTMP1, rd2, #N ADD rTMP1, rTMP1, rd1 LOAD rTMP2, disp(rTMP1) BINOP rTMP2, rTMP2, rs STORE disp(rTMP1), rTMP2 And all it really takes to support this is just adding a second (smaller) ALU on your chip to do addressing calculations.

andrepd 11mo ago
Would this matter for performance? You already have so many execution units that are actually difficult to keep fully fed even when decoding instructions and data at the speed of cache.
- gpderetta 11mo ago
  Yes. As Joker_vD hints on a sibling comment, this is what killed all the classic CISCs during the OoO transition except for x86 that lacks the more complex addressing modes (and the PPro was still considered a marvel of engineering that was assumed not to be possible).
rocqua 11mo ago
There's also a lot of specialized instructions like AES ones. But the main thing that makes x86 CISC to me is not the actual instruction set, but the byte encoding, and the complexity there.
- Joker_vD 11mo ago
  Eh, that's really just a side effect of almost 50 years of constant evolution from a 8-bit microprocessor. Take look at VAX [0], for instance: its instruction encoding is pretty clean yet it's an actual example of a CISC ISA that was impossible to speed up like, literally: DEC engineers tried very hard and concluded that making a truly pipelined & super-scalar implementation was basically impossible; so DEC had to move to Alpha. See [1] for more from John Mashey. Edit: the very, very compressed TL;DR is that if you do only one memory load (or one memory load + store back into this exact location) per instruction, it scales fine. But the moment you start doing chained loads, with pre- and post-increments which are supposed to write back changed values into the memory and be visible, and you have several memory sources, and your memory model is actually "strong consistency", well, you're in a world of pain. [0] https://minnie.tuhs.org/CompArch/Resources/webext3.pdf https://minnie.tuhs.org/CompArch/Resources/webext3.pdf [1] https://yarchive.net/comp/vax.html https://yarchive.net/comp/vax.html
- 201984 11mo ago
  The classic distinction is that a CISC has data processing instructions with memory operands, and in a RISC they only take register parameters. This gets fuzzy though when you look at AArch64 atomic instructions like ldadd which do read-modify-write all in a single instruction.
  - clausecker 11mo ago
    That's more "load store architecture" than RISC. And by that measure, S/360 could be considered a RISC.
jcranmer 11mo ago
One of my biggest bugbears in CS instruction is the overdue emphasis on RISC v CISC, especially as there aren't any really good models to show you what the differences are, given the winnowing of ISAs. In John Mashey's infamous posts [1] sort of delineating an ordered list from most RISCy to most CISCy, the architectures that are the most successful have been the ones that really crowded the RISC/CISC line--ARM and x86. It also doesn't help that, since x86 is the main goto example for CISC, people end up not having a strong grasp on what features of x86 make it actually CISC. A lot of people go straight to its prefix encoding structure or its ModR/M encoding structure, but honestly, the latter is pretty much just a "compressed encoding" of RISC-like semantics, and the former is far less insane than most people give it credit for. But x86 does have a few weird, decidedly-CISC instruction semantics in it--these are the string instructions like REP MOVSB. Honestly, take out about a dozen instructions, and you could make a solid argument that modern x86 is a RISC architecture! [1] https://yarchive.net/comp/risc_definition.html https://yarchive.net/comp/risc_definition.html
- aengelke 11mo ago
  I fully agree, but: > these are the string instructions like REP MOVSB AArch64 nowadays has somewhat similar CPY* and SET* instructions. Does that make AArch64 CISC? :-) (Maybe REP SCASB/CMPSB/LODSB (the latter being particularly useless) is a better example.)
- clausecker 11mo ago
  You may enjoy the RISC deprogrammer: https://blog.erratasec.com/2022/10/the-risc-deprogrammer.html https://blog.erratasec.com/2022/10/the-risc-deprogrammer.htm...

andrepd 11mo ago

Would this matter for performance? You already have so many execution units that are actually difficult to keep fully fed even when decoding instructions and data at the speed of cache.

gpderetta 11mo ago
Yes. As Joker_vD hints on a sibling comment, this is what killed all the classic CISCs during the OoO transition except for x86 that lacks the more complex addressing modes (and the PPro was still considered a marvel of engineering that was assumed not to be possible).

rocqua 11mo ago

There's also a lot of specialized instructions like AES ones. But the main thing that makes x86 CISC to me is not the actual instruction set, but the byte encoding, and the complexity there.

Joker_vD 11mo ago
Eh, that's really just a side effect of almost 50 years of constant evolution from a 8-bit microprocessor. Take look at VAX [0], for instance: its instruction encoding is pretty clean yet it's an actual example of a CISC ISA that was impossible to speed up like, literally: DEC engineers tried very hard and concluded that making a truly pipelined & super-scalar implementation was basically impossible; so DEC had to move to Alpha. See [1] for more from John Mashey. Edit: the very, very compressed TL;DR is that if you do only one memory load (or one memory load + store back into this exact location) per instruction, it scales fine. But the moment you start doing chained loads, with pre- and post-increments which are supposed to write back changed values into the memory and be visible, and you have several memory sources, and your memory model is actually "strong consistency", well, you're in a world of pain. [0] https://minnie.tuhs.org/CompArch/Resources/webext3.pdf https://minnie.tuhs.org/CompArch/Resources/webext3.pdf [1] https://yarchive.net/comp/vax.html https://yarchive.net/comp/vax.html
201984 11mo ago
The classic distinction is that a CISC has data processing instructions with memory operands, and in a RISC they only take register parameters. This gets fuzzy though when you look at AArch64 atomic instructions like ldadd which do read-modify-write all in a single instruction.
- clausecker 11mo ago
  That's more "load store architecture" than RISC. And by that measure, S/360 could be considered a RISC.

jcranmer 11mo ago

One of my biggest bugbears in CS instruction is the overdue emphasis on RISC v CISC, especially as there aren't any really good models to show you what the differences are, given the winnowing of ISAs. In John Mashey's infamous posts [1] sort of delineating an ordered list from most RISCy to most CISCy, the architectures that are the most successful have been the ones that really crowded the RISC/CISC line--ARM and x86. It also doesn't help that, since x86 is the main goto example for CISC, people end up not having a strong grasp on what features of x86 make it actually CISC. A lot of people go straight to its prefix encoding structure or its ModR/M encoding structure, but honestly, the latter is pretty much just a "compressed encoding" of RISC-like semantics, and the former is far less insane than most people give it credit for. But x86 does have a few weird, decidedly-CISC instruction semantics in it--these are the string instructions like REP MOVSB. Honestly, take out about a dozen instructions, and you could make a solid argument that modern x86 is a RISC architecture! [1] https://yarchive.net/comp/risc_definition.html https://yarchive.net/comp/risc_definition.html

aengelke 11mo ago
I fully agree, but: > these are the string instructions like REP MOVSB AArch64 nowadays has somewhat similar CPY* and SET* instructions. Does that make AArch64 CISC? :-) (Maybe REP SCASB/CMPSB/LODSB (the latter being particularly useless) is a better example.)
clausecker 11mo ago
You may enjoy the RISC deprogrammer: https://blog.erratasec.com/2022/10/the-risc-deprogrammer.html https://blog.erratasec.com/2022/10/the-risc-deprogrammer.htm...