• Alex@lemmy.mlEnglish
    9·
    2 days ago

    That’s not really true. Yes avoiding complex instructions makes the front end easier to pipeline but there are lots of smarts in the backend to do prediction and scheduling to keep the execution units fed. The ISA might be free to use but no one is sharing their highly optimised server silicon architecture designs.

    RISC-V’s challenge is can they standardise the software ecosystem enough that things just work across a multitude of chip providers or does everything devolve into specialist distributions taking advantage of each manufacturers “special sauce” custom instructions.

    Gaining design wins over Arm’s microcontrollers for bespoke hardware was the easy bit. Replacing stuff in the server space is much harder and something that took Arm decades to make inroads into.

    • qprimed@lemmy.mlEnglish
      4·
      1 day ago

      great reply. I am not saying RISC is the panecea, what I am saying is that there are more options for workload optimization further up the stack and rebalancing of the intelligence from the silicon to the software is an advantage.

      some time ago most CISC core design become more RISC-y and, to indulge in some ISA snobbery, I just want to slash and burn the CISC presentation to the software layer. memory is cheap, bus bandwidth is insane - simplification on the ISA just seems like a hardware complexity win all around and I am willing to pay for that in compiler complexity that incorporates changes more easily than hardware or CISC microcode.

      RISC-V’s challenge is can they standardise the software ecosystem enough[…]

      agreed. this is why I say my wait may be coming to an end.

      personally, I think RISC is the more flexible design in almost every usecase. cycle for cycle, RISC hits the right buttons for me across the widest number of situations once we get above the “magic hardware” layer. willing to flog the CISC vs RiSC horse convo if you have recent information, and thanks for the response.