* rvv: vmadc/vmsbc have been separated into carry and no-carry versions
Signed-off-by: Chih-Min Chao <chihmin.chao@sifive.com>
* rvv: rename file name by opcode name change
Signed-off-by: Chih-Min Chao <chihmin.chao@sifive.com>
Off by one error meant an external interrupt was prioritised over the
non-standard interrupts (going against what the comment stated was the
intended behaviour).
based on riscv-privilege spec, section 3.1.9
"If supervisor mode is implemented, bits mip.SEIP and mie.SEIE are
the interrupt-pending and interrupt-enable bits for supervisor-level
external interrupts. SEIP is writable in mip, and may be written by M-mode
software to indicate to S-mode that an external interrupt is pending"
Signed-off-by: Chih-Min Chao <chihmin.chao@sifive.com>
- Post arch review updates to the entropy source:
- New address is 0x546
- Removed old references to mentropy and mnoise.
- Throw invalid opcode exception when reading without writing.
- Missing: mseccfg register with SKES bit. Waiting for rest of
register to be implemented.
On branch master
Your branch is up-to-date with 'origin/master'.
Changes to be committed:
modified: riscv/encoding.h
modified: riscv/entropy_source.h
modified: riscv/processor.cc
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
- These are no longer needed since none of the scalar crypto instructions
overlap their encodings any more.
- There is more code to be removed in relation to letting Spike handle
overlapped RV32/64 instructions, but this will be done in subsequent commits
and PRs so that the downstream scalar-crypto work can be un-gated.
On branch scalar-crypto
Changes to be committed:
modified: riscv/encoding.h
On branch scalar-crypto
Changes to be committed:
modified: riscv/insns/sm3p0.h
modified: riscv/insns/sm3p1.h
modified: riscv/insns/sm4ed.h
modified: riscv/insns/sm4ks.h
- Words shouldn't be swapped based on enddianness; the lower-numbered
register always holds the low-order bits.
- Check for alignment, which also fixes a buffer overflow.
- Handle x0 correctly: read as zero, discard writes.
When V=1, vsstatus.MXR applies to the first stage of translation,
and mstatus.MXR applies to both.
mstatus.SUM doesn't apply when V=1, but vsstatus.SUM does.
The previous scheme flushed the TLB before and after HLV/HSV. I think
this was slightly wrong in the case of a debug trigger match: because
the TLB gets refilled before the trigger exception gets thrown, we might
not have reached the second TLB flush, so the entry could linger.
Instead of flushing, simply don't access the TLB and don't refill the
TLB for these instructions. Other than the trigger exception case,
the effect is the same: we'll perform a full table walk and we won't
cache the result.
* 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
The wrong instruction might've been fetched when the PC was on the same
page as a load or store used within the MPRV sequence.
Fix by not using TLB within MPRV sequences.
Resolves#746
When U-mode is enabled but S-mode is disabled, `mcounteren` should control the availability of the hardware performance-monitoring counters in U-mode, and `scounteren` should be ignored.
The current implementation (incorrectly) raises an illegal instruction trap when reading performance-monitoring counters in U-mode while S-mode is disabled, even if the counters are enabled in `mcounteren`.
Chih-Min Chao
Greg Chadwick
marcfedorow
Daniel Lustig
Ben Marshall
Andrew Waterman
ChunPing Chung
Chih-Min Chao
Lu_Reaper
sven
Shay Aviv
Jiuyang Liu