Comment by 80x86

3 days ago

100% agree with dmitrygr.

I was excited when I heard about the project just after it started. However, past experiences taught me to wait before getting excited about the new 'shiny thing'. I did it differently with RISCV. I waited. I am glad I did. It took a long time for actual silicon to appear. Also, the silicon today has all the facepalming special cases mentioned in the article. Its almost like those old soviet era cpus that had the list of bad instructions handwritten on the package.

Overall, RISCV was a minor spin on MIPS, but without really learning from other processors.

So why is everyone still pushing for it? It has the words 'open' on it. People pattern match on that marketing.

As part of that marketing, they also pushed this attitude from the project... 'RISC won'. I think Chester Lam said it best when he wrote his essay stating that RISC didn't win... OoO archs won. I couldn't articulate that nearly as well as he did. If you haven't read it, I recommend it.

So, yeah, here we are. Many people will follow the bandwagon, but they will find that RISCV will not make a significant difference.

I am glad we still have Arm (in all its many forms), x86, and others. (btw, despite my username, I don't think x86 is the best either :-)

Also, if you aren't trying to ship a product, you can experiment with ISAs on an fpga. Yes, fpgas are a lot slower, but they are also a lot more fun. Especially with the great work done to create open source toolchains. Heck, if you are really serious (slighly crazy), you can build your own chip. For the foreseeable future ASIC shuttles are available at prices under $10k. (again, you have to be a little crazy)

5 comments

80x86

Reply
p_l  2 days ago

I'd say RISC won, when you consider how "RISCy" x86 is[1] compared to the ur-CISCs (68k, VAX) that RISC projects were in opposition to.

[1] Not because of often-called "risc like" microcode engine, but because the most complex addressing mode on x86 usually decodes two microinstructions, and decodes in single cycle. In comparison VAX needed separate pipeline for instruction decoding.

  • peterfirefly  12 hours ago

    > In comparison VAX needed separate pipeline for instruction decoding.

    That's how the VAX 9000 and NVAX did it. It's not the only way. It is absolutely possible to decode a number of normal VAX instructions in parallel using a pipelined decoder similar to x86 decoders. It is also possible to use a µop cache similar to many x86 and ARM implementations.

    Fallbacks are only needed for the weirder addressing modes and for instructions that positively beg to microcoded (system calls/protection level transitions, some bit vector stuff, COBOL decimal stuff, block copy/scan/fill/compare, probably POLY) and startup and interrupt/exception handling.

    DEC never did this but they absolutely could have.

    • p_l  12 hours ago

      X86 does not really need pipelined decoders like NVAX did. The complex decode for x86 is the fast path for NVAX without going into CSU. And CSU is where all the more complex addressing modes on VAX end up going - the complex instructions are executed, yes slowly, but in separate unit once CSU finishes the decode for them (and even for packed decimal stuff I-box can theoretically decode in nearly one cycle if all operands are register or immediate). uop cache I'd admit could help for some cases, but still leaves you with even a simple ADD instruction possibly expanding into ~7 uops, maybe 3-4 if we assume big fused equivalent of LEA but then 2 of those will still stall with memory requests.

      DEC didn't try to parallelize the decoder further because it already could face 56 bytes for a single instruction, and the NVAX design was costly as hell. x86 in comparison has limit of max 15 bytes per instruction, and most instructions in x86 code fall in 4 bytes

  • rnvannatta  1 day ago

    The two winning instruction sets are the RISCiest CISC, x86, and the CISCiest RISC, arm.