This makes what are configuration and what are internal SCons variables
explicit and separate, and makes it unnecessary to call out what
variables to export to C++.
These variables will also be plumbed into and out of kconfiglib in later
changes.
Change-Id: Iaf5e098d7404af06285c421dbdf8ef4171b3f001
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/56892
Reviewed-by: Andreas Sandberg <andreas.sandberg@arm.com>
Maintainer: Gabe Black <gabe.black@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
The default constructor for RegId would initialize it with the
IntRegClass and register index 0. This is arbitrary and
indistinguishable from a real ID to the first integer register.
Instead, add a new class type constant InvalidRegClass, and use that to
initialize an otherwise uninitialized RegId.
Also, fill out some enums that needed to handle that value to silence
compiler warnings.
Change-Id: I3b58559f41adc1da5f661121225dbd389230e3af
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/49710
Reviewed-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
Maintainer: Giacomo Travaglini <giacomo.travaglini@arm.com>
Tested-by: kokoro <noreply+kokoro@google.com>
The Request::NO_ACCESS flag instructs the cpu model to not issue
the request to the memory port.
While Atomic and Timing CPU models properly implement it [1], [2],
* MinorCPU is not looking at the flag
* O3CPU is looking at the flag only in case of a nested transaction
start/commit
This patch is extending NO_ACCESS support to all memory instructions.
This is achieved by using the localAccess callback in the Request object.
Handling of nested hardware transactions in the O3 LSQUnit is moved within
the local accessor callback
[1]: https://github.com/gem5/gem5/blob/v21.1.0.2/\
src/cpu/simple/timing.cc#L318
[2]: https://github.com/gem5/gem5/blob/v21.1.0.2/\
src/cpu/simple/atomic.cc#L396
Change-Id: Ifd5b388c53ead4fe358aa35d2197c12f1c5bb4f2
Signed-off-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/56591
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: ZHENGRONG WANG <seanyukigeek@gmail.com>
Reviewed-by: Jason Lowe-Power <power.jg@gmail.com>
Maintainer: Jason Lowe-Power <power.jg@gmail.com>
Individual register files, like the ones for scalar integer, floating
point, or condition code registers, are now declared as vectors of their
actual type. Accessing them is simple, since the register you want can
be accessed simply by indexing into the vector.
Unfortunately, that means the code that sets up that storage has to know
what that underlying type is, and that means knowing (and hard coding)
information about the ISA being built.
Instead, this change makes the SimpleThread and O3 PhysRegFile classes
store registers as vectors of bytes, and offsets into those vectors
using computed offsets. Because the elements of the register files are
forced to be offset by powers of 2, computing the offsets can be done
with a shift rather than a multiplication.
The accessors which actually pull values in and out of these vectors are
still specific to each register type and need to know what the
underlying type is, but this change pulls that one level out of the CPUs
towards their peripheral APIs. Later changes will factor these uses out
as well.
Change-Id: I5e19d359a0e83e5827ae263d369999f90c7aa63d
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/49105
Maintainer: Gabe Black <gabe.black@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
These registers used to be accessed with a two dimensional index, with
one dimension specifying the register, and the second index specifying
the element within that register. This change linearizes that index down
to one dimension, where the elements of each register are laid out one
after the other in sequence.
Change-Id: I41110f57b505679a327108369db61c826d24922e
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/49148
Reviewed-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
Maintainer: Giacomo Travaglini <giacomo.travaglini@arm.com>
Tested-by: kokoro <noreply+kokoro@google.com>
The BaseCPU type had been specializing itself based on the value of
TARGET_ISA, which is not compatible with building more than one ISA at a
time.
This change refactors the CPU models so that the BaseCPU is more
general, and the ISA specific components are added to the CPU when the
CPU types are fully specialized. For instance, The AtomicSimpleCPU has a
version called X86AtomicSimpleCPU which installs the X86 specific
aspects of the CPU.
This specialization is done in three ways.
1. The mmu parameter is assigned an instance of the architecture
specific MMU type. This provides a reasonable default, but also avoids
having having to use the ISA specific type when the parameter is
created.
2. The ISA specific types are made available as class attributes, and
the utility functions (including __init__!) in the BaseCPU class can
refer to them to get the types they need to set up the CPU at run time.
Because SimObjects have strange, unhelpful semantics as far as assigning
to their attributes, these types need to be set up in a non-SimObject
class, which is then brought in as a base of the actual SimObject type.
Because the metaclass of this other type is just "type", things work
like you would expect. The SimObject doesn't do any special processing
of base classes if they aren't also SimObjects, so these attributes
survive and are accessible using normal lookup in the BaseCPU class.
3. There are some methods like addCheckerCPU and properties like
needsTSO which have ISA specific values or behaviors. These are set in
the ISA specific subclass, where they are inherently specific to an ISA
and don't need to check TARGET_ISA.
Also, the DummyChecker which was set up for the BaseSimpleCPU which
doesn't actually do anything in either C++ or python was not carried
forward. The CPU type still exists, but it isn't installed in the
simple CPUs.
To provide backward compatibility, each ISA implements a .py file which
matches the original .py for a CPU, and the original is renamed with a
Base prefix. The ISA specific version creates an alias with the old CPU
name which maps to the ISA specific type. This way, old scripts which
refer to, for example, AtomicSimpleCPU, will get the X86AtomicSimpleCPU
if the x86 version was compiled in, the ArmAtomicSimpleCPU on arm, etc.
Unfortunately, because of how tags on PySource and by extension SimObjects
are implemented right now, if you set the tags on two SimObjects or
PySources which have the same module path, the later will overwrite the
former whether or not they both would be included. There are some
changes in review which would revamp this and make it work like you
would expect, without this central bookkeeping which has the conflict.
Since I can't use that here, I fell back to checking TARGET_ISA to
decide whether to tell SCons about those files at all.
In the long term, this mechanism should be revamped so that these
compatibility types are only available if there is exactly one ISA
compiled into gem5. After the configs have been updated and no longer
assume they can use AtomicSimpleCPU in all cases, then these types can
be deleted.
Also, because ISAs can now either provide subclasses for a CPU or not,
the CPU_MODELS variable has been removed, meaning the non-ISA
specialized versions of those CPU models will always be included in
gem5, except when building the NULL ISA.
In the future, a more granular config mechanism will hopefully be
implemented for *all* of gem5 and not just the CPUs, and these can be
conditional again in case you only need certain models, and want to
reduce build time or binary size by excluding the others.
Change-Id: I02fc3f645c551678ede46268bbea9f66c3f6c74b
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/52490
Reviewed-by: Andreas Sandberg <andreas.sandberg@arm.com>
Maintainer: Gabe Black <gabe.black@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
If there really are no c++ sim_objects in the file, then sim_objects can
be set to [] which it used to default to.
This way, if someone hasn't remembered to update their SConscript files
for the new sim_objects and enums parameters, this will give them some
indication what's wrong, rather than the build just failing later.
Change-Id: Ic1933f7b9dfff7dd7e403c6c84f1f510c8ee8c72
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/54203
Maintainer: Gabe Black <gabe.black@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Andreas Sandberg <andreas.sandberg@arm.com>
This was originally intended to make it more efficient to get the
microPC without making a copy of the entire PCState object to return.
Now that the PCState is returned through a pointer without a copy and
the microPC can be accessed with an inline accessor, we don't need to
create a special accessor for it.
Change-Id: I1d354dfca6be5d954e147f23dc9d27917b379bf2
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/52061
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Daniel Carvalho <odanrc@yahoo.com.br>
Maintainer: Gabe Black <gabe.black@gmail.com>
The "Regs" structure in the DynInst class was using placement new to
allocate register arrays in a dynamically allocated blob which can be
resized based on the number of source and destination registers.
Unfortunately, it was assumed that the alignment of the components of
that structure would work out because they were ordered from largest to
smallest, which should imply largest alignment to smallest.
This change instead uses an overloaded new operator to allocate extra
memory for the DynInst itself, and then initialize arrays within that
extra space. The DynInst class then gets pointers to the arrays so it
can access them. This has the benefit that only one chunk of memory is
allocated, instead of one for the DynInst and then a second for the
arrays.
Also, this new version uses the alignof operator to figure out what
alignment is needed for each array, which should avoid any undefined
behavior. The new-ing, initialization, destructing, and delete-ing are
also more carefully orchestrated. Hopefully one or both of these will
squash potential memory management bugs.
Change-Id: Id2fa090b53909f14a8cb39801e9930d4608e42f7
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/52485
Reviewed-by: Gabe Black <gabe.black@gmail.com>
Reviewed-by: Daniel Carvalho <odanrc@yahoo.com.br>
Maintainer: Gabe Black <gabe.black@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
There are a few places where TheISA::PCState is still necessary,
specifically when checking if a PC is branching, and also when getting
the nextInstAddr.
It's likely that checking if a PC is branching will become part of the
base PCState interface, but nextInstAddr will likely be removed from the
ThreadContext, ExecContext, etc, interfaces, and then removed from the
interfaces in the O3 which doesn't seem to use them internally.
Change-Id: I499f31d569b9b0c665a745caf612d1e96babf37a
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/52051
Tested-by: kokoro <noreply+kokoro@google.com>
Maintainer: Gabe Black <gabe.black@gmail.com>
Reviewed-by: Daniel Carvalho <odanrc@yahoo.com.br>
There is a function for this purpose in RegId called flatIndex(), which
I had attempted to use with PhysRegId which inherits from RegId.
Unfortunately, PhysRegId redefines the flatIndex() method and makes it
do something completely different, which is to turn map the index into a
linearization of all registers in the CPU.
Instead of using the decoy wrong method, and because the one we actually
want is not accessible, we can just manually compute the flattened index
in the two places we use it.
Change-Id: I8bd02f0be0f4fb3742da48b2955e9e75ec57245b
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/52603
Reviewed-by: Jason Lowe-Power <power.jg@gmail.com>
Maintainer: Jason Lowe-Power <power.jg@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
This simplifies the O3 CPU, and removes special cases around how vector
registers are handled. Now ARM is responsible for maintaining its
different register personalities internally.
Also, this re-establishes the invariant that registers are indexed as
complete, opaque entities with no internal structure, at least as far as
the CPU is concerned.
To make sure the KVM CPU sees the correct state, we need to sync over
the vector registers if we're in 32 bit mode when moving state to or
from gem5's ThreadContext.
Change-Id: I36416d609310ae0bc50c18809f5d9e19bfbb4d37
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/49147
Reviewed-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
Maintainer: Giacomo Travaglini <giacomo.travaglini@arm.com>
Tested-by: kokoro <noreply+kokoro@google.com>
These are called from the ThreadContext, and should not be counted in
the statistics. The (read|set)*Reg methods, aka readIntReg and not
readArchIntReg, are called from the (read|set)*RegOperand methods in the
DynInst, which is the ExecContext implementation when running on O3.
Change-Id: I9abf90fc7bbe80a742325b6dfd3c0e14392af54c
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/51428
Maintainer: Gabe Black <gabe.black@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
This virtual method can trivially be shared among different CPUs, making
it unnecessary to cast from a BaseCPU pointer to some more specific CPU
class. The existing similar functions which implement this functionality
are only trivially different, and can be merged into overloads of this
common method.
Noteably this method is not implemented for the MinorCPU which uses the
SimpleThread class, typedef-ed to be MinorThread. If the previous
version of this method had been called on that CPU, it would have
crashed the simulator since a dynamic_cast would have failed. This
doesn't provide an implementation for the MinorCPU, but it also doesn't
make the problem worse, and provides a way to actually implement it some
day.
Change-Id: I23399ea6bbbbabd87e6c8bf7a66d48902745d2cf
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/52084
Reviewed-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
Maintainer: Giacomo Travaglini <giacomo.travaglini@arm.com>
Tested-by: kokoro <noreply+kokoro@google.com>
The LSQSenderState that was attached to Request was not useful.
All the fields were either a duplicate of information in the
LSQRequest or totally unused.
The LSQRequest class now inherits from Packet::SenderState and is
attached to the Packet that are sent to memory. We do not need
anymore the indirection Packet->SenderState->LSQRequest.
This helps making the code clearer as it was sometimes hard to
follow the difference between what the LSQRequest and
LSQSenserState was doing
(ex: number of outstanding requests in the memory).
Change-Id: I5b21e007e6d183c6aa79c27c1787ca56dcbc3fb0
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/50733
Reviewed-by: Bobby R. Bruce <bbruce@ucdavis.edu>
Maintainer: Bobby R. Bruce <bbruce@ucdavis.edu>
Tested-by: kokoro <noreply+kokoro@google.com>
