Since mtime and mtimecmp both initialize to 0, and "a machine timer
interrupt becomes pending whenever mtime contains a value greater than
or equal to mtimecmp," MTIP should be 1.
Before this change, MTIP would be 0 until the first increment, or
until reading/writing from CLINT regs (since clint_t::load() and
clint_t::store() call increment(0)).
std::min takes its arguments by reference, so the arguments need to be
defined. An alternative would have been to force the problematic argument
into being an rvalue (e.g., by adding 0), but this approach seems to me
to be more robust.
This fixes compilation under -O0; see https://github.com/riscv-software-src/riscv-isa-sim/pull/1264#issuecomment-1451114717@scottj97 I posit that this situation is unusual enough that it shouldn't
motivate us to test -O0 in CI.
This is a large delta because the old implementation baked in multiple
assumptions about the contiguity of hart IDs.
As a side effect, fix implementation for big-endian hosts.
This commit started as an attempt to make the PLIC tolerant of
discontiguous hart IDs, but it turns out it was already most of
the way there: PLIC contexts can still be dense even if the hart
IDs are not.
Nevertheless, I wanted to avoid passing the procs vector directly to
the plic_t constructor. In removing it, I realized I could also get
rid of the smode parameter by querying whether each hart has S-mode.
This is also more correct; previously, we were instantiating the PLIC
as though all harts had S-mode, regardless of whether they actually did.
Debug spec says:
Because chain affects the next trigger, hardware
must zero it in writes to mcontrol that set dmode
to 0 if the next trigger has dmode of 1. In addition
hardware should ignore writes to mcontrol that
set dmode to 1 if the previous trigger has both
dmode of 0 and chain of 1. Debuggers must avoid
the latter case by checking chain on the previous
trigger if they’re writing mcontrol.
Previously, this was ignoring the write even if it was coming from
M-mode and therefore would have had dmode forced to 0. That should not
count as a "write to mcontrol that sets dmode to 1".
Maintain a shadow structure of isa_parser_t::extension_table,
processor_t::extension_enable_table, which tracks whether such
extensions have been dynamically enabled or disabled.
Sanity-check that `extension_enabled_const` honors its contract.
The use of `mutable` is somewhat unfortunate, but we think it's
acceptable here because the only thing that's mutating is this
sanity-checking code, not visible to any consumer of this class.
!dtb_enabled will now result in the following behavior:
* sim_t.dts and sim_t.dtb will be empty
* the dtb_file passed to sim_t will be ignored
* The default bootrom will not be instantiated
* Bus devices normally configured by parsing the dtb will not be added
This includes the CLINT/PLIC/UART