Using the register destination to store an immediate result causes the isa parser to set the destination as a dependency, meaning the destination register from previous instructions must have a ready result before this instruction can issue. I fixed several cases where this occurs by using a non register intermediary value
Change-Id: Id2ccca820a4e072fa2cae81fa9153deb6a8d5c4c
Signed-off-by: Noah Katz <nkatz@rivosinc.com>
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/63052
Maintainer: Jason Lowe-Power <power.jg@gmail.com>
Reviewed-by: Jason Lowe-Power <power.jg@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
The way these were set up, there would be a conflict between SimObject
files with the same name set up for different ISAs.
This change creates a single file which tries to determine how many ISAs
are enabled, and if there is exactly one, it creates a backwards
compatible alias for the ISA specific CPU types.
Change-Id: Iab358c2880d49222e814a98354c81d0f306fe1fc
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/52493
Reviewed-by: Andreas Sandberg <andreas.sandberg@arm.com>
Maintainer: Gabe Black <gabe.black@gmail.com>
Reviewed-by: Gabe Black <gabe.black@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Maintainer: Andreas Sandberg <andreas.sandberg@arm.com>
The TARGET_ISA variable would let you select one ISA from a list of
possible ISAs. That has now been replaced with USE_ARM_ISA, USE_X86_ISA,
etc, variables which are boolean on or off. That will allow any number
of ISAs to be enabled or disabled individually. Enabling something other
than exactly one of these will probably prevent you from getting a
working gem5 binary, but those problems are being addressed in other,
parallel change series.
I decided to use the USE_ prefix since it was consistent with most other
on/off variables we have in gem5. One noteable exception is the
BUILD_GPU setting which, you could convincingly argue, is a better
prefix than USE_. Another option would be to use CONFIG_, in
anticipation of using a kconfig style config mechanism in gem5.
It seemed premature to start using a CONFIG_ prefix here, and if we
decide to switch to some other prefix like BUILD_, it should be a
purposeful choice and not something somebody just starts using.
Change-Id: I90fef2835aa4712782e6c1313fbf564d0ed45538
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/52491
Tested-by: kokoro <noreply+kokoro@google.com>
Maintainer: Gabe Black <gabe.black@gmail.com>
Reviewed-by: Jason Lowe-Power <power.jg@gmail.com>
Reviewed-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
Previously, all components assume the info in arch/riscv/regs/misc.hh to
be the single source of CSR info. That will however make adding
non-standard CSRs difficult as all those CSRs will need to go into the
same header & data structure and might conflict with each other.
In this CL, we add two new functions to the ISA class that provide
information about CSR. The rationale is that, the ISA class is already
the owner of CSR data, so it'll also be in a better position to provide
necessary CSR metadata. With the change, we can create two CPU models
with slightly different custom CSRs easily by creating two derived
RiscvISA classes and overriding the two functions.
We assume that, any customized CSR set is still compatible with standard
CSRs, so we could still utilize the same global map if only standard
CSRs are accessed in the use case.
Note that this does not necessarily mean you cannot or should not add
your customize CSRs into the MiscRegIndex enum. You'll usually still
required to do that to give each CSR an unique id. However, the ability
to override CSRDataMap/CSRMaskMap provide an opportunity to remap how
the CSR index encoded in the instruction maps to CSR, and also give you
a chance to make the read/write logic of certain custom CSRs different.
Change-Id: I168188bdb1baed11cb3e217eb021f289a13bb036
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/62891
Reviewed-by: Jason Lowe-Power <power.jg@gmail.com>
Maintainer: Jason Lowe-Power <power.jg@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Translation entries from regimes with no ASID support are
tagged as global.
For complete translations we cannot simply check for the EL
being EL2 or EL3 as the EL2&0 translation regime does support
ASIDs to differentiate userspace host applications.
We therefore change the LongDescriptor::global method to cover
the EL2&0 case.
We also fix the partial translation logic which was labelling
partial translations as non global without checking for the
translation regime
Change-Id: I9375a34eba6ede97d70ed80e43ce363a57678d55
Signed-off-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/62452
Maintainer: Andreas Sandberg <andreas.sandberg@arm.com>
Maintainer: Jason Lowe-Power <power.jg@gmail.com>
Reviewed-by: Jason Lowe-Power <power.jg@gmail.com>
Reviewed-by: Andreas Sandberg <andreas.sandberg@arm.com>
Tested-by: kokoro <noreply+kokoro@google.com>
In commit 83b14e56, getVirtProxy is replaced by inline ternary operators
to decide between FS or SE version. However, dynamic dispatch will not
work in this scenario and the virtual function of SETranslatingPortProxy
will not be called. It may lead to failure in m5op read_file in SE mode.
Change-Id: I9b5f757096cfdbd6fb8bc14b1b0e02245703a0ac
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/62611
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Jason Lowe-Power <power.jg@gmail.com>
Maintainer: Jason Lowe-Power <power.jg@gmail.com>
BasicDecode, or decode block templates in general, contains the template
for substituting the return statement returning a StaticInst given a
machine code.
In the case of micro-coding an instruction, this return statement is for
the macro op. Additionally, in gem5 riscv, the spawned micro-ops will be
added in the macro op constructor, which is done in the macro-op
constructor template. Thus, there's no need for having a return statement
for the micro-op.
Currently, there are two return statements in decode-method.cc.inc for
each riscv atomic inst. This change removes one of the two BasicDecode
blocks in atomic inst templates.
This change is expected to a cosmetic change.
Change-Id: Id14bde25d5d3f164b4faafd33bfd5c802a94ca09
Signed-off-by: Hoa Nguyen <hoanguyen@ucdavis.edu>
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/62492
Reviewed-by: Jason Lowe-Power <power.jg@gmail.com>
Maintainer: Jason Lowe-Power <power.jg@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
The previous implementation used the physical memory view when reporting
memory back to GDB. This circumvents MMUs and caches, and leads to wrong
backtraces at the least.
Current architectures support EL3, EL2, and EL1/EL0, and the Iris
interface presents a Msn that corresponds to that (`0x10ff`), see
table "Canonical memory space numbers" in the Iris user guide.
As GDB expects the view of the processor when querying memory (e.g. for
backtraces), this will allow proper backtraces.
Not sure if there is an implicit way of expressing memory attributes
(like in Lauterbach with the access modifiers before address
specifications), or if there is a need to implement special monitor
commands. But for the common use, using `CurrentMsn` should be the
correct choice.
Change-Id: Ibd14c1f94163105539a7fb9132550fe713b5c295
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/61951
Reviewed-by: Gabe Black <gabe.black@gmail.com>
Maintainer: Gabe Black <gabe.black@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Current WFI implementation always put the CPU to sleep even if there's
an pending interrupt. This might cause issue because an interrupt might
happen just before the WFI is executed, and there might not be any
further interrupts to wake the CPU up, so the CPU sleeps indefinitely.
In this CL, we ensure the CPU sleeps only if there's no pending
interrupt at all, regardless whether the interrupt is masked or not. We
intentionally check for masked interrupt as well because a masked
interrupt is also able to wake the CPU up if it occurs after WFI. This
will make the behavior consistent no matter the interrupt comes before
or after WFI.
Change-Id: I74dbc01fed52652101675f1ae8e481b77c932088
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/62251
Tested-by: kokoro <noreply+kokoro@google.com>
Maintainer: Jason Lowe-Power <power.jg@gmail.com>
Reviewed-by: Jason Lowe-Power <power.jg@gmail.com>
This implements flattening in the x86 integer and floating point
RegClass-es, as well as adding regName functions for each. These came
from the X86StaticInst::printReg function, and the flattening functions
in the X86ISA::ISA class.
Change-Id: If026e3b44aa64441222451d91e99778f6054d9f0
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/51228
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Gabe Black <gabe.black@gmail.com>
Maintainer: Gabe Black <gabe.black@gmail.com>
Most of the invalidation methods in the TLB class are
doing the same thing: looping over all entries, checking if
the entry matches a certain criteria, and invalidating it
in case it does.
The only specific bit is the matching function, therefore
we add a virtual TLBIOp::match method which allows us
to specialize different TLBIs and to provide a single
flush method in the TLB class
Change-Id: I0672ff958742ac7ebff8d30218f75127343f1a58
Signed-off-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/61753
Reviewed-by: Andreas Sandberg <andreas.sandberg@arm.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Maintainer: Andreas Sandberg <andreas.sandberg@arm.com>
Reviewed-by: Richard Cooper <richard.cooper@arm.com>
The method is no longer calling the lookup method which
had been complicated by the introduction of partial translations.
(which is now called during address translation only)
The lookup method is iterating over all TLB Entries until a non
partial translation is found. Using lookup in flushMva makes it
O(n^2). With this patch we iterate over the TLB entries only once
(making flushMva O(n))
Change-Id: I8f2ae56192812cee231baf6943068abea4d7ef91
Signed-off-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/61752
Maintainer: Andreas Sandberg <andreas.sandberg@arm.com>
Reviewed-by: Andreas Sandberg <andreas.sandberg@arm.com>
Reviewed-by: Richard Cooper <richard.cooper@arm.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Fixing invalidation behaviour for the following stage 2 TLB maintainance
instructions
MISCREG_TLBI_IPAS2E1_Xt
MISCREG_TLBI_IPAS2LE1_X
MISCREG_TLBI_IPAS2E1_Xt
MISCREG_TLBI_IPAS2LE1_Xt
1) Do nothing if EL2 is not enabled in the current security state
2) If we are in secure state, the 63 bit of the Xt register selects
the security domain (s/ns) of the invalidated entries
Change-Id: I4573ed60ce619bcefd9cb05f00c5d3fcfa8d3199
Signed-off-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/61751
Reviewed-by: Andreas Sandberg <andreas.sandberg@arm.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Richard Cooper <richard.cooper@arm.com>
Maintainer: Andreas Sandberg <andreas.sandberg@arm.com>
Replace the two constructors with one that takes the truly mandantory
parameters, and then a function to derive a new RegClass with some sort
of adjustment, currently by adding custom ops, or setting a non-standard
register size.
Because the constructor and the modifier function are constexpr, they
should fold away and not actually create extra temporary copies of the
RegClass in the modifier functions.
Change-Id: I8acb755eb28fc8474ec453c51ad205a52eed9a8e
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/50249
Tested-by: kokoro <noreply+kokoro@google.com>
Maintainer: Giacomo Travaglini <giacomo.travaglini@arm.com>
Reviewed-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
