Skip to content

Latest commit

 

History

History
50 lines (34 loc) · 4.3 KB

rv32zild_proposal.adoc

File metadata and controls

50 lines (34 loc) · 4.3 KB
Raw

Zild v0.10

This document is in the Discussion Document state. Assume everything can change. This document is not complete yet and was created only for the purpose of conversation outside of the document. For more information see: https://riscv.org/spec-state

Zild (working title) is a RV32-only extension, with the sole purpose of enabling the LD (64-bit register load) and SD (64-bit register store) instructions from RV64.

Rationale

The motivation behind this proposal is a combination of multiple use-cases:

  • Performance: in applications with very tight inner-loops, the ability to issue multiple register loads with a single instruction can be beneficial in order to meet tight real-time requirements where every CPU cycle counts. If the CPU bus interface is 64 bits or wider this will also allow for better utilization and double the throughput compared to just LW.[1]

  • Atomicity: in some cases, the ability to read or write two 32-bit registers in an atomic fashion can be beneficial

  • Zdinx: with the Zdinx extension, the LD instruction can be used to load a double-precision floating-point value into two adjacent integer registers for use by the FP ops; directly replacing the FLD instruction.

  • Code size (in case the compressed encodings are included): being able to encode two adjacent 32-bit loads/stores with a single compressed instruction could have the potential to save quite a bit of code size (measurements/bencmarking would be needed to determine how much).

Instructions

This proposed extension doesn’t specify any new instructions per se, it only adds support for instructions which already exist in the 64-bit base ISA to RV32.

The instructions will follow the same restrictions in terms of register specification as the Zdinx extension:

  • Registers are allocated in pairs with r containing the low-order bits (31:0) of the 64-bit value, and (r+1) containing the high-order bits (63:32).

    • This alignment applies regardless of machine endianness.

  • Only even-numbered registers may be used - odd-numbered register encodings are reserved.[2]

    • If x0/zero is specified as the rs2 source operand of a store operation, zero should be written for both words - regardless of the contents in x1.

    • Conversely, if x0/zero is specified as the destination, x1 should not be updated with the upper half of the result.

The following instructions would be added (enabled) by this extension:

  • LD: 64-bit data load into {rd+1, rd} from memory address stored in rs1 (+ immediate)

  • SD: 64-bit data store from {rs2+1, rs2} to memory address stored in rs1 (+ immediate)

(Optional) compresed encodings

If the compressed extension Zca is enabled, then we can add the RV64C encodings for 64-bit loads as well:

  • C.LD: 64-bit data load

  • C.SD: 64-bit data store

  • C.LDSP: 64-bit data load (stack-pointer relative)

  • C.SDSP: 64-bit data store (stack-pointer relative)

This is of course incompatible with the (RV32) F extension, as those opcodes are then occupied by the single-precision load/store ops (C.FLW, C.FSW, C.FLWSP and C.FSWSP respectively). Therefore those instructions should be added as a separate Zcld or similar sub-extension (or naturally follow if Zild and Zca [but not Zcf] are enabled).
Because of the [restrictions] imposed on register selection, 1 bit of all the compressed encodings (the ones for rs2[0] and rd[0]) can be reserved and thus we free up half the code points for future use.

1. While the same could be achieved using macro-op fusion, having a dedicated instruction for this makes it easier for smaller implementations with simple decoders and short pipelines to utilize this. The most realistic alternative for most smaller implementations would be to fuse two adjacent C.LW instructions, as anything else would require a decoder wider than 32 bits and/or multiple decode stages - all adding complexity and (power/area) cost.
2. Since this restriction is already in place for the Zdinx extension it makes sense to keep it here as well