add WRITE_FRD macro redirect

changed style, can revert changes to amomin/max

add frs2 redirect

add RS3 replacement

simplify sv_proc_t redirection of RS1-3 / FRS1 macrhos

redirect RS2 to sv_proc_t class

proof-of-concept, redirect RS1 to class sv_proc_t

combination of redirection through a "property" class overloads WRITE_RD

WRITE_RD, formerly a macro, now replaced with a function.
also required a redirector function rd

redirect instructions through a class called sv_proc_t

preparing the groundwork for a total over-ride of macros such as
WRITE_RD, and so on, so that element width can be implemented

more explicit testing, duplicating header file algorithms for div, rem and shift

whoops run from 0-255 not 0-254, and other test corrections

add some operator tests for int8_t being typecast to uint16_t

add more experimenting on operators

add operators test class

add operators library to contain operator-overloads of +/-/*/div/>/>= etc

for all types int8, uint8, float16_t, float32_t etc.

all to be template-ified

get predicated-vectorised branch working

save branch address and predication merged result, and test after branch

if the predication was all good, go ahead with the branch

still not tested for predicated / vectorised branch yet however
at least scalar branches work

add explanatory comment

add explanatory comment

start adding explicit twin-predicated branch identification (rs2)

extend sv register file from 64 to 128 after discussion.

evaluation of even embedded GPUs shows that they have really enormous
register files.  a fp16 x 4 to express quads, times four, takes up eight
consecutive registers just on its own.

override setpc macro so that sv can redirect it in branch

this is slightly complicated.  setpc is a global macro, intended for
use in the templates.  however for SV it needs to be conditional,
so needs to redirect to a function in sv_insn_t.

that in turn needs quite a few extra parameters: the current loop
element offset, the argument to set_pc just in case actually it is
detected that this really is to be a branch not a predication scenario
and so on.

have not tried out vectorisation yet, at least straight non-vectorised
branch operations (unit tests) pass.

swap #ifdef USING_NOREGS so that it is possible to redefine set_pc

to avoid having to modify the branch instructions the set_pc macro will
be #undefd and redefined to modify the predication target

add rd bit-setting function

add extra debug printing for c.lwsp

add rvc_swsp_imm sv overload, provides vector unit stride now

c.swsp and c.fswsp predication and offset enabling

allow x2 (sp) to be redirected in C.LWSP

temporary hack disabling SV in anything other than user mode

whoops inverted ldsp and lwsp immediates

create ldsp immediate offset overrides

this allows C.LWSP/C.LDSP to do predicated load/stores from contiguous
blocks of memory

add in predication for immediate, for C.LWSP

reorganise src and dest vector-element offsets

pass in pointer to offsets from processor_t->state.srcoffs and destoffs
into sv_insn_t so that the element state information about how many
parallel elements have been executed is recorded.

in this way it will be possible to restart a loop at the right place
if there is an exception (such as a memory cache miss on a LOAD/STORE)

add srcoffs and destoffs sv state, alter CSRs

remove SVREALVL, replace with SVSTATE

reorganise twin-predication

move the offset incrementing to outside of the sv_insn_t, and pass in
the src_offs and dest_offs by reference, mirroring and matching the
predication src and dest referencing

big reorganisation to support twin-predication

twin predication is on certain operations like LOAD, STORE, C.MV, FCVT
where the effect is similar to VSPLAT, VINSERT, and also bitmanip
scatter/gather.

add in twin-predication identification

pass in second predicate for twin-predication operands

decided not to change the behaviour of LOAD/STORE

start work on parallelsing LOAD, pass in parameter to reinterpret immed

debug print for floating-point regs

add comment explaining why invert isnt done in zeroing test
(already inverted basically)

add comment explaining use of insn._rd() in zeroing

whoops vloop continuation logic the wrong way round

the loop has to continue if there is one vectorised register left
rather than stop if there is *no* vectorised registers

skip parallelisation of complex LR/SC operations

identify type of instruction with additional #defines

add a #define to id_regs.py which indicates name of the instruction

the c preprocessor cannot cope with detecting what the name of the
instruction is (and when it does, if it is "and" that throws a
compile-error), so as a workaround have id_regs.py create a
#define INSN_ADD, #define INSN_ADD_I etc.

list of instructions to avoid parallelising

update template comment

lots of debugging of predication, found other errors

lots of stuff here:
* changed sv reg and pred entry layout to make them a bit more
  human-readable: put the key and idx on byte-boundaries
* bug in SV REG setting (getting int table instead of fp one, twice)
* bug(s) in SV PRED table setting (zeroing the reg tables, using idx not
  key and more)
* stop lookup of predication if the *REGISTER* entry is inactive
  (but not if it is a scalar, because scalar predication is ok)
  this was the final piece of the puzzle that got predication working
* added a useful macro for creating SV REG and PRED CAM table entries

predication now working including zeroing

add sv support for zeroing predication in dest register

bit of a major rework:

* access to the "unpredicated" (non-zero-hacked) register was needed
* therefore all rd/rs1-3/rvc_xxx functions had to have _ variants
* the underscored variants are not predicated
* this in turn meant that the offset for each register was wrong
  as it is incremented *after* being checked
* therefore a newoffs had to be added
* and the reset_cache function copies the newoffs values

bit of a mess but it works: this is a state machine after all...

add in predication to sv instruction execution

this relies on setting the value of the destination register
(and source registers) to zero.  a bad hack but it will do

start linking in predication into sv

use an alternative logic for detecting scalar / loop-end

instead of pre-checking do the check for "all-scalar" during the
first loop iteration i.e. when registers are first accessed

add compressed-identifying patterns to id_regs.py

also skip LUI (and C.LUI) as non-paralleliseable instructions

fix code template for when SPIKE_SIMPLEV is not defined

yuk. break id_regs.py being a generic tool by skipping csr ops

trying to use c preprocessor macros to skip CSRs in sv from being
parallelised is too painful, and is necessary to do.  a parallel CSR
read/write does not make sense

fix bug in sv template where FRS2 was checking rs3

add checks for RVC registers to sv template

add sv_insn_t overloads for rvc registers

also arrange for id_regs.py to identify compressed instruction usage

a LOT of debugging and fixing, sv loop actually working

move SV CSRs to user-read-write

add near-duplicate of SV CFG REG CSRs, for predication

add implementation of CSR SV CFG regs 0-7

this is a CAM table of key-value entries, 5-bits key (from instruction)
6-bits value (actual register table, now 64 entries)

TODO: obviously RV32E that would be reduced.
TODO: make it optional to have 32-32

assign SV REG CSRs (using new union ability)

make sv csr tables a union so they can be assigned to a ushort easily

add support for CSR_SVVL to CSRRWI as well

fix bug in CSR set SVVL: val has already been looked up

csrrw.h has been modified to invert the order of set/get, so the
call to processor_t::set_csr(SVVL, val) will do the right thing
and the subsequent (delayed) call to get_csr will return the
state.vl value in the chosen RD

all good

add stub for SV REG configs

stop a compiler warning

reorganise from moving sv_pred_* and sv_reg_* tables into processor_t

have to move SV CSRs into processor_t

add 8 CSRs for registers and predication each

each CSR contains 2 16-bit entries and is a CAM based on register as
key (5-bit) and target-register as value (6-bit) so that a 5-bit
RS1-3/RD can actually reach 64 actual registers, and *3-bit C instructions
can as well*

whoops dont need separate SVSETVL/SVGETVL CSRs

also add SVREALVL which is needed for state context save/restore

revert addition of svsetvl as an actual opcode, add mvl CSR instead

this is less than ideal but better than having to add new opcodes

Revert "sv setvl as a csr not going to work, add getvl only"

This reverts commit 996e0246aa614231a560f3e3e84793745470ca6f.

Revert "manually add svsetvl instruction"

This reverts commit b3e60c2c6e722bc181369d48642834422fa1082c.

manually add svsetvl instruction

sv setvl as a csr not going to work, add getvl only

adding sv vector length CSR to processor state, and csr get/set

32 CSRs are used up, here, as SETVL requires not only an immediate
but also a target integer register in which the SETVL value is
stored.

add sv predication function

save some cpu cycles by |ing the checks for vectorop together

whoops vectorop has to be |= not &= to accumulate "true"

cache the sv redirected register values on each loop

if an emulated opcode ever calls insn.rd() or rs1-3 more than once
sv_inst_t::remap would accidentally increment the loop offset before
it was time to do so.

therefore put in a cacheing system and clear it only at the end
of each loop

remembered that the use of sv registers have to be loop-incremented separately

the SV parallelism loop has to respect whether each *individual* register
is a vector or a scalar.

clarify comments on (key strategic) sv_insn_t::remap function

actually implement sv register re-mapping

the algorithm here checks the (required) table (int or fp), checks if
the entry is "active", does a redirect, then checks if the entry is
scalar or vector.  if vector, the loop-offset (passed by value) is
added

ok this is tricky: an extra parameter has to be passed into sv_insn_t::remap

the reason is that the remap has to know if the register being
remapped is an int or a float.  the place where that is known
is at *decode* time... and that means that id_regs.py has to
look that up and pass it on (in a #define REGS_PATTERN).
the reason it is passed in as a pattern is so that svn_insn_t rd/rs1-3
have access to the information that is needed

move sv remap function to sv.cc (not inline)

check if register redirection is active, and if vectorisation enabled

check each register (if used) - this is what the #define USING_RD etc.
macros are for, to disable checks that are not needed

comment why sv_insn_t is set up the way it is; add vector loop stub

easier to #define USING_NOREGS if the opcode does not use any registers

include auto-generated identification of use of registers per op

modified id_regs.py to take a single argument (file in riscv/insns to parse)
added call to id_regs.py in riscv.mk.in
included the auto-generated file in the insn_template.cc

now each instruction has a way - BEFORE the emulated instruction is called -
to identify which registers (RD, RS1-3, FRD, FRS1-3) are going to be used.

shuffle things around a bit for sv, put rv32/64_name back to like they were

decided to move sv to its own template file, and make a bit more use
of macro pre-processing

skip id_reg.py parsing its own output; stop outputting "0" on empty

change to instruction template parsing, create one file per instruction

id_regs.py looks for patterns in riscv/insns/*.h to find the use of
registers

add decode.h header to sv.h

rename sv vlen to sv voffs, add csr and reg tables

add reference to vector length in sv

use sv_insn_t class in instruction template