[libre-riscv-dev] [isa-dev] SV / RVV, marking a register as VL.
luke.leighton at gmail.com
Thu Aug 29 09:55:58 BST 2019
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
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
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,
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.
More information about the libre-riscv-dev