No support for RV32E

[nwf-msr]

There is no mechanism to signal that only half the register file is available. In particular,

QuickCheckVEngine/src/QuickCheckVEngine/Templates/Utils/General.hs

Lines 166 to 169 in 0873b58

	-- | 'inUseReg' generates a register index from the "in use registers",
	-- currently one of r0, r1, r2, r3, r4, r16, r17, r18, r19 and r20
	inUseReg :: Gen Integer
	inUseReg = oneof [choose (0, 4), choose (16, 20)]

hard-codes the availability of a subset of registers that straddle the E/I divide. The ubiquity of this generator (through its aliases as src and dest) probably makes refactoring for principled plumbing of configuration tedious, if not challenging.

[gameboo]

@nwf-msr I am not sure of all the ramifications, or how many spare cycles we have regarding this, but specifically here, the obvious thing to try out to see if it helps would be to use something like inUseReg = oneof [choose (0, 4), choose (11, 15)]

[nwf-msr]

Oh, indeed, it's possible to hack something like that in, and indeed it does placate the CHERIoT sail model, but more generally, it would be nice to have TestRIG understand the E architectural subset.

[gameboo]

I am not extremely familiar with E beyond it requiring implementations to throw exceptions on forbidden register indices.

QCVengine wants to generate indices which would trigger exceptions, as you'd want to test both paths...
Do you mean maybe that you'd want a knob to tell which registers to allocate more often than the others?
I suppose that could be a nice feature (feels orthogonal to the E extension, just being able to specify register ranges from the command line...). Implementing that would basically require something along the lines of passing down the information from the command line arguments, I guess similar to the way the other dynamically parameterized chunks of code are doing it... Not sure there is a fundamentally nicer way.

Were you thinking of other things?

[nwf-msr]

As I read the spec, RV32E cuts the register file in half (x0 - x15) and promises not to use any of the freed up encodings for official extensions, but designates them as available for vendors. But yes, mostly "don't generate vendor-private opcodes in arithmetic tests" was what I had in mind. :)

[jrtc27]

It's also specified in such a way that you are intended to be able to run RVE code on an RVI system (which of course implicitly precludes the existence of custom extensions snatching up that encoding space), as another reason why it's not a requirement that those encodings trap.

[nwf]

Oh exciting. At some point since filing, the RISC-V spec has changed the E extension and now says:

The previous draft of this chapter made all encodings using the x16-x31 registers available as custom. This version takes a more conservative approach, making these reserved so that they can be allocated between custom space or new standard encodings at a later date.