3

Suppose you take an RV32 program and try running it on a 64-bit system, what compatibility issues are likely to arise?

As I understand it, the instruction encoding is the same, and on RISC-V (like other modern RISC architectures, though unlike x86), ALU operations automatically operate on whatever the word size is, so if you add the contents of a pair of registers, you will get a 32-bit or 64-bit addition as applicable. Load and store of course work on an explicitly specified size because they depend on how many bytes have been allocated in memory.

One theoretically possible compatibility issue would arise if the code depends on bits past 32 being discarded, e.g. add 2^31 to itself and compare the result with zero.

Another more practical issue would arise if the operating system supplies memory addresses outside the first 4 gigabytes, which would be garbled when the code stores the addresses in 32-bit variables.

Are there any other issues I am missing?

rwallace
  • 31,405
  • 40
  • 123
  • 242

1 Answers1

2

You are correct about both of those possible compatibility issues.

Additionally, some Control and Status Registers (namely cycleh, instreth, timeh) are not needed in RV64I and therefore don't exist. Any code which tries to access them should error.

However, there are instructions to use only the lower 32 bits for ALU operations. Which could potentially be changed by replacing the opcode and funct3 in the binary.

So with an operating system mode which returns only 32-bit addresses, it would be possible to replace a binary with a working 64 bit version so long as cycleh and friends aren't used.

References RISC-V Specification v2.2:

  • Chapter 4 of the RISC-V Spec. v2.2 outlines the differences from RV32I to RV64I.
  • Chapter 2.8 goes over Control and Status Registers
  • Table 19.3 lists all of the CSRs in the standard.
TheThirdOne
  • 427
  • 3
  • 10