[libre-riscv-dev] stack-based SV CSR tables

[Luke Kenneth Casson Leighton]

ok so after some thought on how to have reasonably efficient
vector-based function calls, particularly, pushing CSRs onto the stack
before a function call and popping them back afterwards, i realised
that the present scheme is inconvenient.  there are (were) 8 fixed CSR
addresses, where in RV64 it was possible to set 4 16-bit CAM entries
at a time, and RV32 only two.

if however the 16 16-bit CAM entries were more like a "stack" - or
more accurately like a SPARC register window - then it might be
possible to push new CSR entries onto the "stack", and if it's too
full, have the CSRRW function return some of the bottom of the stack
in order to make room.  the returned entries could be pushed
*actually* onto the stack (C.SWSP).

so that's what i'm experimenting with, at the moment.  amazingly, the
unit test macros in sv_test_macros.h remain almost exactly the same,
and they do not need to change parameters at all.  the only one that
has had to be modified is CLR_SV_CSRs, and it's one i want to pay some
attention to, next.

the issue with the current scheme is that if you want to call a
function, there's quite a lot of CSR state that needs to be stored, or
altered, and with fixed CSR addresses it's very inconvenient.
realistically it would be necessary to push the entire lot onto the
stack: predicate CSRs as well.

what i'd like to explore is having one CSR and let it be a hybrid
"push to top" and "pop from top", and another which is "push to
bottom" or "pop from bottom".  the "top" one you would use to put new
register entries (and get values that were at the bottom and needed to
be put onto the stack), and the "bottom" one you would use after a
function call returned, to put the old entries *back*.

in this way it becomes possible to pass in "vectorised" registers as
parameters to a function, without disrupting the caller or having too
much in the way of latency.

still got some planning to do.

l.