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?
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.
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?
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:
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.
i’m not sure but i think it’s here: https://hg.sr.ht/~icefox/riscv-reference/browse/instructions.toml