[libre-riscv-dev] spike-sv non-default element widths

[Jacob Lifshay]

On Tue, Oct 9, 2018 at 11:53 AM Luke Kenneth Casson Leighton <lkcl at lkcl.net>
wrote:

> ok adding in native support in spike for non-default element widths is
> a massive task, where i really do not want to do a redesign of spike.
>
That's part of why I originally thought it would be better to write a new
ISA simulator from scratch.

>
> the issue however is that, dynamically, at runtime, all the
> combinations of element bitwidths in all permutations for all
> registers used, need specific code to be generated and then called.
>
> * if rd is to be used, that's 1 dimension of 4 entries: default,
> default/2, default*2 and 8-bit
> * if rs1 is to be used, that's a 2nd dimension of 4 entries
> * if rs2 ...
>
> so that would be SIXTY FOUR possible code-paths (!!!)
>
> and in each case, i think it would be sensible to bring in a
> *template-if-ied* version of the instruction class.  the templated
> version would have overloaded operators +, - > = etc. etc. including
> for floating-point.  unnnnfortunately, floating-point has been done in
> a declarative (non-class-based) fashion, with functions "f64_eq" and
> so on,   there, *maybe* some #defines can work around that.
>
You could overload the f64_eq and family for your class.

>
> the idea is, basically, to have a table of template-ified versions of
> the instruction class that, when declared, pass the element widths in
> and down to the register file.
>
> so, when the index (element offset) is passed in to a request for an
> element (READ/WRITE), an operator "overload" takes care of where the
> data actually goes, performing the required typecasting on the
> register file entry.
>
> it'll be a bit... complex.  thoughts on alternative approaches appreciated.
>
You could have a function that handles all register reads and another
function that handles all register writes and have them handle all the
actual location complexity.

Jacob