Store the upper bits of the PC in a table and only handle indices and
lsbs in the main pipeline.
This eliminates redundancy between PCs and predicted PCs, and even more
between fragments of instructions.
Whilst the current PLIC spec is hard to decipher, the older v1.9
privileged spec is clearer. The intent is that each interrupt is
independent and so claims and completions can be overlapped (e.g. as
done by FreeBSD if deferring an interrupt handler). This is
approximately expressed in the spec by:
The PLIC can perform a claim at any time and the claim operation is
not affected by the setting of the priority threshold register.
...
The PLIC does not check whether the completion ID is the same as the
last claim ID for that target. If the completion ID does not match an
interrupt source that is currently enabled for the target, the
completion is silently ignored.
Thost last two sentences make it sound like the completion ID not
matching the last claim ID is a thing to ignore, but in fact they are
entirely independent statements. This can be confirmed by reading the
source for the Rocket and QEMU PLICs, which have none of the stricter
requirements of the Bluespec PLIC implementation.
This should fix running FreeBSD after r362977, which started to
correctly delay the completion of interrupts until after deferred
handlers had completed (as opposed to after they had been queued).
Raise a store page fault if the PTE is missing R or W, even if the store is a
cap store and the PTE is also missing CW, as per the sail spec.
Co-authored-by: Jessica Clarke <jrtc27@jrtc27.com>
(Previously we ran into the limit of ports on the regFiles holding state
in the BTB. This uses a vector of regFiles with a vector of interfaces,
which is logically the same but might produce multiple copies of state.)
Evidence of "working" is passing TestRIG to a cursory depth including
compressed instructions and running CoreMark in simulation.
This one appears to be 2.5% slower than the existing design in CoreMark,
so some optimisation should be done. We expect it to be a bit faster
than the original due to more flexibility in decoding instructions from
different fetch units together.
