Comment by Joker_vD

Comment by Joker_vD a day ago

9 replies

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.
jcranmer a day 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

rocqua a day 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.

  • 201984 a day 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 8 minutes ago

      That's more "load store architecture" than RISC. And by that measure, S/360 could be considered a RISC.

  • Joker_vD a day 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

    [1] https://yarchive.net/comp/vax.html

andrepd a day 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 19 hours 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).