3 ms·

It’s obvious that if you’re specifically designing a clean sheet ISA, you wouldn’t choose to copy an existing ISA that has seen several decades of backwards com

• drob518 1y ago
  OK, fair enough that one doesn’t necessarily imply the other, but if you were designing a CPU/ISA today, would you start with a CISC design? If so, why?
  • Pet_Ant 1y ago
    I do wonder if CISC might make a comeback. One is cache efficiency. If you are doing many-core (NOT multi-core) than RISC make obvious sense. If you are doing in-order pipelined execution, than RISC makes-sense. But if you are doing superscalar out-of-order where you have multiple execution units and you crack instructions anyway, why not have CISC so that the you have more micro-ops to reorder and optimise? It seems like it would give the schedulers more flexibility to keep the pipelines fed. With most infrastructure now open-source I think the penalty for introducing a new ISA is a lot less burdensome. If you port LLVM, GCC, and the JVM and most businesses could use it in production immediately without needing emulation that helped doom the Itanium.
    • drob518 1y ago
      I agree that cache efficiency is important. You can never have enough L1. It seems to me that compressed instructions ala ARM Thumb and RISC-V Compressed give you most of what you really want. One of the problems in the CISC era was that the compilers actually didn’t generate many of the fancy instructions, so it’s unclear whether you’d get back much from decoding massive amounts of micro-ops and letting the superscaler scheduler work it out if the compiler is mostly generating the simple instructions anyway. That said, the compilers of that era were also less sophisticated, so maybe we’d do better now. In the end, though, I don’t see CISC making any significant come back, other than perhaps in embedded where code size is definitely important and speeds are generally lower and multi-cycle execution is ok. But it feels like we already have all the ISAs we need to cover that space pretty well already.
  • ummonk 1y ago
    I'd do the same thing others are doing, which is a hybrid of classic RISC and CISC elements: * From the RISC side, adhere to a load-store architecture with lots of registers * From the CISC side, have compressed variable length encoding and fused instructions for common complex operations (e.g. multiply-add, compare-and-branch)
    • drob518 1y ago
      That’s the right answer, IMO. To me, that sounds a lot like a RISC with some complex instructions, which is really where all RISCs have landed in any case. That said, I would use fixed length compressed instructions ala Thumb and RISC-V Compressed. And there’s nothing wrong with that patch of design space. That works.
      • ummonk 1y ago
        Thumb was originally fixed length yes, but Thumb-2 introduced 32-bit encoded instructions to complete the set, so it's now variable length encoded. Likewise, RISC-V Compressed only provides compressed encodings of a subset of RISC-V instructions, so binaries that make use of RISC-V Compressed will be variable-length encoded, mixing 16-bit and 32-bit encoded instructions.
        • brucehoult 1y ago
          Historically, having two instruction lengths was common or even the norm for RISC and RISC-like (before the name was made up) register-rich load/store machines including CDC6600, Cray 1, IBM 801 (original 24 bit version), Berkeley RISC-II. It was only RISC ISAs introduced between 1985 (Arm, MIPS, SPARC) and 1992 (DEC Alpha) that had fixed-length 4 byte instructions -- a mere eight years out of the 60 year history of RISC designs.
          • ummonk 1y ago
            Fair point on the RISC-II having non-fixed instruction sizes. In any case, I think it's weird that we've experienced semantic drift to the point that architectures with instruction sets that are too large and complex to be considered reduced get referred to as RISC simply because they're load-store architectures with lots of registers.