Compiling spike with gcc 13 (for example, included in Fedora 38
prerelease) fails with error:
In file included from fesvr/syscall.h:6,
from fesvr/syscall.cc:4:
fesvr/device.h:15:30: error: ‘uint64_t’ was not declared in this scope
15 | typedef std::function<void(uint64_t)> callback_t;
| ^~~~~~~~
This is due to a gcc header dependency change. See for reference:
https://gcc.gnu.org/gcc-13/porting_to.html#header-dep-changes
This commit explicitly adds the missing <cstdint> header inclusion
to fix this build failure.
Signed-off-by: Julien Olivain <ju.o@free.fr>
@aswaterman explains:
Rather than requiring each MMIO device to support arbitrary sizes and
alignments, decompose MMIO misaligned loads and stores in such a way
as to guarantee their constituent parts are always aligned.
(Specifically, they now always decompose to a sequence of one-byte
accesses.)
This is not a semantic change for main-memory accesses, but it is a
semantic change for I/O devices. It makes them more realistic, in that
most bus standards don't support non-power-of-2-sized accesses.
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.
Julien Olivain
Andrew Waterman
Scott Johnson
Jerry Zhao
Sagar Karandikar
Viktor Prutyanov