1. 5
  1.  

  2. 2

    The goal is to cover the entire RV64 user-level instruction set […] RV32 is currently out of scope, but might be nice in the future.

    Isn’t RV64 an extension of RV32, with some additional instructions for larger integers? I feel like you’d have most of the RV32I, at least, by virtue of having done RV64 in the first place.

    Also I am not so familiar with Sourcehut – where is the actual draft guide?

    1. 2

      Isn’t RV64 an extension of RV32, with some additional instructions for larger integers? I feel like you’d have most of the RV32I, at least, by virtue of having done RV64 in the first place.

      At first glance, yes. But at second glance, this is not quite true, or at least while it may be true in practice it is not quite a strict extension in principle. From some of the commentary in the spec, section 1.3:

      The four base ISAs in RISC-V are treated as distinct base ISAs. A common question is why is there not a single ISA, and in particular, why is RV32I not a strict subset of RV64I?

      …[reasons]…

      A related question is why there is a different encoding for 32-bit adds in RV32I (ADD) and RV64I (ADDW)? The ADDW opcode could be used for 32-bit adds in RV32I and ADDD for 64-bit adds in RV64I, instead of the existing design which uses the same opcode ADD for 32- bit adds in RV32I and 64-bit adds in RV64I with a different opcode ADDW for 32-bit adds in RV64I. This would also be more consistent with the use of the same LW opcode for 32-bit load in both RV32I and RV64I. The very first versions of RISC-V ISA did have a variant of this alternate design, but the RISC-V design was changed to the current choice in January 2011. Our focus was on supporting 32-bit integers in the 64-bit ISA not on providing compatibility with the 32-bit ISA, and the motivation was to remove the asymmetry that arose from having not all opcodes in RV32I have a *W suffix (e.g., ADDW, but AND not ANDW). In hindsight, this was perhaps not well-justified and a consequence of designing both ISAs at the same time as opposed to adding one later to sit on top of another, and also from a belief we had to fold platform requirements into the ISA spec which would imply that all the RV32I instructions would have been required in RV64I.

      Basically, teasing out all the details that may differ is more work than I want to do for now. Plus a spec for RV64 will be 99% valid for RV32 anyway, so I don’t see a great benefit to separating the two. I’m more interested in phone/desktop-class RISC-V stuff than embedded right now, though I confess I may be in the minority there.

      1. 2

        Also I am not so familiar with Sourcehut – where is the actual draft guide?

        i’m not sure but i think it’s here: https://hg.sr.ht/~icefox/riscv-reference/browse/instructions.toml