Now it disassembles 0x0000 (invalid encoding of c.addi4spn) as c.unimp
(RVC). Non-RVC variant of unimp pseudoinstruction (0xc0001073) is also
implemented.
Krypto 1.0 changes: Entropy source CSR, name.
List scalar crypto instruction groupings, as there is no single K extension.
Co-authored-by: Markku-Juhani O. Saarinen <mjos@mjos.fi>
Optimize the hash functions for RISC-V instruction encodings. This is
only a perf optimization; instructions that don't adhere to RISC-V
standard practice will still disassemble correctly, just more slowly.
- Remove remaining code which allowed spike to differentiate between
RV32 and RV64 instructions which share an encoding.
On branch scalar-crypto
Changes to be committed:
modified: disasm/disasm.cc
modified: riscv/processor.cc
* Priv virtual memory updates
* Priv 1.12 requires page faults when the address translation process
reaches a PTE with any reserved bit set
* Svpbmt uses two PTE bits, but otherwise has no effect on Spike (since
Spike is sequentially consistent and does not model PMAs)
* Add Svinval instructions
Even though I updated riscv-opcodes separately, I merged the new
defines into riscv/encoding.h manually, because riscv-opcodes seems
to be a step ahead of riscv-isa-sim for a few vector opcodes, causing
conflicts when regenerating encoding.h...
If that gets fixed, and encoding.h gets regenerated automatically, I can
remove it from this PR to avoid conflicts.
* Svinval: use #include rather than copying code
..for the Svinval functions that are implemented in ways that just
mimic SFENCE/HFENCE instructions
Thanks to @aswaterman for the suggestion
Historically, one could uniquely decode any RISC-V instruction based on
the instruciton to decode, plus a MATCH and MASK pair.
The scalar crypto extension adds instructions for accelerating the AES
algorithm which work very differently on RV32 and RV64. However, they
overlap in terms of opcodes. The instructions are always mutually
exclusive, and so it makes sense to overlap them this way to save
encoding space.
This exposed a problem, where previously Spike assumed the decoder
function was something like:
> decode(instr_word, MATCH, MASK)
Now it needed to be
> decode(instr_word, MATCH, MASK, current_xlen)
To get around this in the initial implementation, the instructions which
shared opcodes were implemented in the same *.h file - e.g. aesds.h
contained an implementation of aes32dsi, and aes64ds. We detected
xlen in the file, and executed the appropriate instruction logic.
This worked fine for our limited set of benchmarks.
After more extensive testing, we found that Spike has an optimisation
which changes the order in which it tries to decode instructions based
on past instructions.
Running more extensive tests exposed the fact that the decoding logic
could still not unambiguously decode the instructions. Hence, more
substantial changes were needed to tell spike that an instruction is
RV32 or RV64 only.
These changes have been implemented as part of
- riscv/encoding.h
- disasm/disasm.cc
- riscv/processor.cc/h
Basically, every instr_desc_t has an extra field which marks which
base architecture the instruction can be exectuted on. This bitfield
can be altered for particular instructions.
The changes to riscv/insns/* simply split out the previously combined
instructions into a separate header files.
On branch scalar-crypto-fix
Changes to be committed:
modified: disasm/disasm.cc
modified: riscv/encoding.h
new file: riscv/insns/aes32dsi.h
new file: riscv/insns/aes32dsmi.h
new file: riscv/insns/aes32esi.h
new file: riscv/insns/aes32esmi.h
new file: riscv/insns/aes64ds.h
new file: riscv/insns/aes64dsm.h
new file: riscv/insns/aes64es.h
new file: riscv/insns/aes64esm.h
deleted: riscv/insns/aesds.h
deleted: riscv/insns/aesdsm.h
deleted: riscv/insns/aeses.h
deleted: riscv/insns/aesesm.h
modified: riscv/processor.cc
modified: riscv/processor.h
modified: riscv/riscv.mk.in
Weiwei Li
Andrew Waterman
Yueh-Ting (eop) Chen
Tsukasa #01 (a4lg)
Markku-Juhani O. Saarinen
marcfedorow
Chih-Min Chao
Ben Marshall
Daniel Lustig
Chih-Min Chao
ChunPing Chung