[libre-riscv-dev] [isa-dev] SV / RVV, marking a register as VL.

[lkcl]

On Thursday, August 29, 2019 at 8:53:53 AM UTC+1, lkcl wrote:
 

> ok so here there's a dependency: VL has a read dependency on a2. x0 is not 
> written to, so there's no write dependency created.
>

so here's the thing: (thanks to rogier for going over some of the 
alternatives, it allows clear highlighting by comparison of the benefits of 
this idea)

as long as VL is not read via a CSRR, it's actually completely out of the 
picture as far as dependency-tracking is concerned.  where in the current 
version of RVV it is the "exception" - the problematic CSR that requires 
close arithmetic tie-in, when it is made into a 
pointer-to-a-scalar-that-is-used-instead, it becomes just like every other 
CSR is supposed to be.

at that point, some interesting microarchitectural design-decisions (and 
compromises) come back into play:

(1) where before, due to its close tie-in, VL could in no way be left out 
of full first-order dependency-tracking, its change in role now allows it 
to be considered a "second-rate" CSR, where accessing it results in 
"stalls", thus greatly simplifying the architecture and reducing gate count.

(2) as it is the only one, VL may be hardware-cached, i.e. the fact that it 
points to a scalar register, well, that's only 5 bits: that's not very much 
to pass round and through pipelines.

(3) if it's not very much to pass around, then the possibility exists to 
*rewrite* a CSRR VL instruction to become a MV operation, *at execution 
time*!

yes, really: at instruction *decode* time, with there being only the 5 bits 
to check "if VL-cache-register is non-zero and CSR register == VL", it's 
really not that much extra logic to *directly* substitute the CSRR 
instruction with "MV rd, 
VL-where-VL-is-actually-the-contents-of-the-VL-cache"

that would then allow the substituted-instruction to go directly into 
dependency-tracking *on the scalar register*, nipping in the bud the need 
for special CSR-related dependency logic, and no longer requiring the 
sub-par "stall" solution, either.

overall i think it's not so much a nightmare: it's just different (as all 
new ideas are), and, ultimately, it's solvable.

l.