4 ms·

Why bother with bespoke bytecode when we have a high quality, standard ISA? RISC-V's base RV64I has 47 instructions. Legacy ISAs can simply emulate these 47 in

• adrian_b 3y ago
  Bytecode is presumably chosen to minimize the program length, while the RISC-V is at the opposite end of verbosity for representing a program. You may be one of those who believe that RISC-V is a high-quality ISA, but this is not an universal opinion and it is a belief that is typically shared only by those who have been exposed to few or no other ISAs. In the context of something like ACPI, I would be worried by the use of something like the RISC-V ISA, because this is an ISA very inappropriate for writing safe programs. Even something as trivial as checking for integer overflow is extremely complicated in comparison with any truly high-quality ISA.
  • Joker_vD 3y ago
    For example, Open Firmware specification used a flavour of Forth for its bytecode.
  • IshKebab 3y ago
    How patronising. Can you give an example of an ISA that is higher quality than RISC-V?
    • patmorgan23 3y ago
      Well first you need to define your criteria for "high quality"
      • snvzz 3y ago
        The parent (adrian_b) has to, if anyone. But as far as I can see, they simply have a (misguided) preference for CISC. They're very vocal against load/store architectures, and they don't seem to understand the tradeoffs RISC-V does make. They don't even seem to get that RISC-V has had the highest density in 64bit from the start (first ratified user spec, 2019), and now has highest density among the 32bit too (as of recent Zc ratification).
    • Joker_vD 3y ago
      WDC 65C02, or even WDC 65C816. Or how about MMIX?
    • adrian_b 3y ago
      There is no doubt that Aarch64 is a much higher quality ISA than RISC-V. The good or bad licensing model used for an ISA has nothing to do with the technical quality of an ISA. Even the Intel/AMD ISA, despite its horrible encoding, after excluding many hundreds of obsolete instructions that are not needed any more and after excluding from the instruction encoding the prefix bytes that are needed only for backward compatibility, would be a higher quality ISA than RISC-V, especially for expressing any task that is computationally intensive. RISC-V is particularly bad for expressing computations with big integers. The modern subset of the Intel/AMD ISA is better than RISC-V even from the point of view of some of the design criteria on which RISC-V is based. For instance, the designers of RISC-V have omitted many useful features under the pretext that for good performance those features would require additional read and write ports to the register file. The Intel/AMD ISA, by allowing one of the three operands of an instruction to be a memory operand, allows identical performance with an ISA with 3 register operands, while having one less read port and one less write port in the register file. Having instructions with one memory operand works well only in CPUs with out-of-order execution. Nevertheless, the same performance as for an ISA with a memory operand can be achieved in a low-cost in-order CPU if there are a set of explicitly addressable load buffer registers, and one or more operands of an instruction can be a load buffer, instead of a general-purpose register. So there would have been many better ways of accomplishing the design criteria of RISC-V. RISC-V is a simple ISA that is great for teaching, but its only advantage over any ISA that a competent designer could conceive in a few days is the large amount of already existing software tools, i.e. compilers, linkers, debuggers and so on, which would take years to duplicate for any brand-new ISA.
    • stephen_g 3y ago
      I’ve heard really good things about SuperH (sh-2, sh-4 etc.), designed by Hitachi for their processors including those used in the Sega Saturn and Sega Dreamcast. Really high code density was one big thing, but it was covered by patents until recently. There was a group trying to make a modern open source processor in VHDL for FPGAs and later on ASICs based on it, but I think it may have mostly fizzled out.
      • TapamN 3y ago
        I do Dreamcast homebrew, and my opinion is the SH ISA is way over-optimized for 90's embedded applications. It wastes the tiny instruction space on useless things like read-modify-write bit operations, intended for setting hardware registers, and has a laughably small displacement for function calls (+/-2KB, with pretty much all calls requiring manually loading a function pointer from RAM). There are parts that are still nice compared to something like RISC-V, like post-increment loads and pre-decrement stores (but hardware designers seem to hate things like that, since they require an extra write port on the register file), and the code density can be pretty good (although GCC's output is awful), but there are so many ways the ISA could be easily improved.
        • roytam87 3y ago
          (sorry for being off-topic) regarding https://news.ycombinator.com/item?id=16308439 https://news.ycombinator.com/item?id=16308439, I wonder how is this project going?
          • TapamN 3y ago
            I haven't done much on it since then. While it's something I would like to finish, I realized that there are other, higher priority things that I should do first.
• saagarjha 3y ago
  What makes you think RISC-V is a good fit for device configuration?
  • snvzz 3y ago
    Simplicity, lack of flags or arithmetic exceptions, as well as clear ABI and environment call mechanism. Hardware access could be clearly gated through ecalls, and the mechanisms for this could exist as a standard extension in the SBI interface.