This commit adds the *.pc files for Spike's simulation library,
enabling dynamic and static linking without the need to directly
reference Spike sources. Using Spike as a stand-alone library
provides an interesting option for developing tools
and applications based on Spike.
None of these cases are perf-critical.
It was easy to change one of them to use std::string, but the others
would have required more refactoring. So, simply change them to use
snprintf instead.
The shift amount is 6 bits wide on RV64. As with the base ISA shifts, we
ignore XLEN and unconditionally disassemble the 6-bit immediate on RV32.
Partially reverts da93bdc435
Iterate over the instruction chains in reverse order, prioritizing
the last call to `disassembler_t::add_insn`.
To preserve behavior for the standard instructions, reverse the order
in which we add instructions in the `disassembler_t` constructor.
Supersedes #995.
Before this patch, spike just had an "Xbitmanip" extension which
covered everything in the proposed bitmanip extension that hadn't been
ratified. The problem is that if you want to model (or verify) a
processor that targetted just some of the proposed bitmanip extension,
you couldn't configure Spike to do that.
For example, the lowRISC Ibex processor has several different
configurations. The "balanced" configuration targetted Zba, Zbb, Zbs,
Zbf and Zbt of the 0.92 spec. With the Zba, Zbb and Zbs ratified,
we'll now be able to use an ISA string like
rv32imc_Zba_Zbb_Zbs_XZbf_XZbt
and Spike will correctly fail to decode instructions like 'bcompress',
which would have been decoded with Xbitmanip.
This patch adds a new custom extension name for each part of the
extension that wasn't fully ratified. These have an 'X' prefix so, for
example, the bit permutation instructions that were proposed as Zbp
can be found under XZbp.
Specifying "Xbitmanip" gets all of these extensions, so its behaviour
should be unchanged.
Note that the slo(i) / sro(i) instructions have been moved from the
proposed Zbb to XZbp. This matches a comment in the Change History
section of v0.93 of the bitmanip spec: it seems that the authors
forgot to also move them in Table 2.1 (which gives the lists of
instructions for each extension). This change won't break anything
that currently exists, but it took quite a while to figure out what
was going on so I thought I'd leave a breadcrumb trail for the next
engineer!
The bulk of the patch is just defining some more entries in the
isa_extension_t enum and rewriting each of the instructions to depend
on the relevant entry. This is mostly a straight textual replacement
but it's slightly more complicated for things like the "pack"
instruction that are defined by several different proposed extensions.
It's helpful to attempt to disassemble instructions for disabled
extensions, so attempt to do so. Since some extensions conflict
in the opcode space, continue to give higher priorty to explicitly
enabled extensions.
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.
Precompiled headers were broken because they weren't compiled with
the same -fPIC setting as the rest of the code. Fix by just making
everything use -fPIC.
- 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
Gianluca Guida
Andrew Waterman
Weiwei Li
Wojciech Bartczak
Neel Gala
Jerry Zhao
Kip Walker
liweiwei90
Yan
Rupert Swarbrick
Yueh-Ting (eop) Chen
Tsukasa #01 (a4lg)
Markku-Juhani O. Saarinen
marcfedorow
Chih-Min Chao
Ben Marshall
Daniel Lustig
Chih-Min Chao
ChunPing Chung