4 ms·

Beyond RISC – The Post-RISC Architecture (1996)

• ncmncm 5y ago
  I'm ready for Risc-6 already. A Risc-6 could fix mis-designed details of RISC-V while remaining similar enough to get advantage of the verification work already done. We will each have a list of fixes to offer. My first is a popcount feature in the core definition. It need not be an instruction; it could be a field of the status register that also records =0, sign, carry, and overflow. Instead of just the one status register, to be renamed at need the way x86 and ARM do lately, I would append these bits to every register, carried along with the value. My second would be to make the logical true value physically equal to ~0, both in the ISA and in the C/C++/Rust ABI. (This does not, of course, affect how it looks from the source-code level.) I could go on, but others will have their own suggestions.
  • jabl 5y ago
    If you want a "RISC-like" ISA, I think ARM64 is pretty good, actually.
  • deleted 5y ago
    [deleted]
  • Findecanor 5y ago
    I don't think it would be a bad idea to make a small extension to RISC-V that handles overflow and carry bits. Such functionality is sorely needed not just for arbitrary-precision arithmetic (bignum libs, Python, Ruby, Smalltalk, ...), but more importantly for languages that rely on checking overflow (Rust, Ada, Swift, ...). Implementing the flags as register metadata is probably the best way, yes. A "pcnt" instruction is already in the "B"it manipulation extension, which IMHO should be compulsory for a non-embedded RISC-V CPU anyway.
    • ncmncm 5y ago
      The extensions not in the core profiles look to turn out to amount to a cruel joke: specified but never available in hardware, implemented if at all via trap and emulation, so that any attempt at optimization using them becomes, instead, extreme pessimization.
  • colejohnson66 5y ago
    > Instead of just the one status register, to be renamed at need the way x86 and ARM do lately, I would append these bits to every register, carried along with the value. Is there any difference? I doubt that Intel and AMD rename the status flags separately. For example, Skylake-X has the same number of physical flags “registers” as physical GPRs.[0] [0]: https://travisdowns.github.io/blog/2020/05/26/kreg2.html https://travisdowns.github.io/blog/2020/05/26/kreg2.html (the skinny register file next to the GPR ones)
    • ncmncm 5y ago
      If you need to rename registers, renaming a status register is no more trouble. But having only one way, in the ISA, to mention status is limiting in the same way as having too few named registers.
      • colejohnson66 5y ago
        How so?
        • ncmncm 5y ago
          It means that, at the ISA level, only one status can be considered live at any instruction address. If you will need it later, but need to generate another status result, you have to copy the old value somewhere. This is much like in x32, where you had only one visible named AX register, and had to spill its value if you needed it for something else.
• jabl 5y ago
  Why did these dataflow architectures never succeed? It seems, on the surface, like a good idea. Did encoding the instruction dependencies bloat I$ usage to the point that the advantages were lost? Any current research in this area?