Move the instDone flag, and the instReady function which was
consistently implemented just to return it, to the base InstDecoder
class. This flag can still be accessed easily from the subclasses, but
now it can be retrieved with just an InstDecoder pointer without a
virtual function call.
Change-Id: I8c662aa01da8fe33ffe679071c701e0aadc1a795
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/52072
Reviewed-by: Daniel Carvalho <odanrc@yahoo.com.br>
Maintainer: Gabe Black <gabe.black@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Most of the time, the type pointed to by a PCState pointer or reference
will be the same as all the others, if not nullptr.
This change adds a set of "set" functions which assume that the
underlying type of each pointer or reference are the same, and handles
casting, copying things over, creating a new copy, etc, for you. It uses
a new "update" virtual method on PCState subclasses which casts the
source to the same type as the destination and copies values over.
Note that the "set" function doesn't actually verify that the two types
are the same, just like the overloaded ==, != and << operators. In the
future, those checks can be added for debugging purposes, probably
guarded by a configuration variable which can be toggled on or off to
get better performance or more thorough error checking.
The main advantage of these wrappers are that they allows consistent
semantics whether your moving a value from a pointer, or from a yet
unconverted PCState subclass, or vice versa, which will be particularly
helpful while transitioning between using raw PCState instances and
using primarily pointers and references.
This change also adds wrappers which handle std::unique_ptr, which makes
it easier to use them as arguments to these functions. Otherwise, if the
std::unique_ptr is a temporary value, using the return value of .get()
will let the std::unique_ptr go out of scope, making it delete the data
pointed to by the returned pointed. By keeping the std::unique_ptr
around on the stack, that prevents it from going out of scope.
Change-Id: I2c737b08e0590a2c46e212a7b9efa543bdb81ad3
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/52041
Tested-by: kokoro <noreply+kokoro@google.com>
Maintainer: Gabe Black <gabe.black@gmail.com>
Reviewed-by: Daniel Carvalho <odanrc@yahoo.com.br>
This method is the seed which creates a new PCState object of the
appropriate type. It can be used to initialize PCStateBase *s so that they
always point to something valid and can be manipulated without having to
first check if there's something there, as opposed to the alternative
where a pointer might be null until it's first pointed at something.
Change-Id: If06ee633846603acbfd2432f3d8bac6746a8b729
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/52040
Reviewed-by: Daniel Carvalho <odanrc@yahoo.com.br>
Maintainer: Gabe Black <gabe.black@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Introduce a virtual output() method which prints the current PCState to
the given output stream, and define an overload for << to use that
method. This will make it possible to print a PCState without knowing
what the actual type is.
Change-Id: I663619b168c0b2b90c148b45ae16d77f03934e5b
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/52039
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Bobby R. Bruce <bbruce@ucdavis.edu>
Maintainer: Bobby R. Bruce <bbruce@ucdavis.edu>
Also move up the accessors for them. By putting the storage in the base
class, we can keep the accessors non-virtual and keep their overhead
low. Subclasses will be free to set those values to whatever they want
with no overhead, just as if they were natively part of that class.
Change-Id: I58e058def174e0bf591c0a9f050c23f61e9d8823
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/52037
Reviewed-by: Daniel Carvalho <odanrc@yahoo.com.br>
Maintainer: Gabe Black <gabe.black@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
This will let callers create a separate copy of a PCState class
instance. This makes it more explicit when creating copies of a PCState
to make sure the programmer is more aware, and avoids having to know
what the actual type is to make a copy.
Change-Id: I728a278afdb55b800c753a5b7f65f62f4a80c043
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/52035
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Daniel Carvalho <odanrc@yahoo.com.br>
Maintainer: Bobby R. Bruce <bbruce@ucdavis.edu>
These helpers will make it easier to cast a PCStatePtr into an ISA
specific class with less syntactic fluff. They are currently implemented
with a static_cast for performance reasons, but could be implemented
with a dynamic_cast and an assert for extra debugging if you were
willing to pay the performance overhead. In the future this might be
switched/enabled as an extra debugging mode, like how locking can have
extra checks enabled in the Linux kernel.
Change-Id: Ibc2443c6b991ebc2e5d0240a88436849cb6de2b9
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/52033
Tested-by: kokoro <noreply+kokoro@google.com>
Maintainer: Bobby R. Bruce <bbruce@ucdavis.edu>
Reviewed-by: Daniel Carvalho <odanrc@yahoo.com.br>
This class has a lot of common functionality which all PCState classes
use, but in order to make it a true base class which provides the
complete interface for PCState-s throughout gem5, all its methods would
need to become virtual. That doesn't have to be the case today because
we use the literal full ISA specific PC class directly, but we need to
move away from that.
This change leaves PCStateBase empty, since we don't know what will need
to be accessible in base classes through a common/virtual interface.
Also, move methods which do not depend on the InstWidth template
parameter out of SimplePCState and into PCStateCommon. This avoids
having duplicate methods with the same contents which don't depend on
InstWidth.
Change-Id: I31309c4f35e897db1bc8318439fae1567a82b35e
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/52031
Reviewed-by: Daniel Carvalho <odanrc@yahoo.com.br>
Reviewed-by: Earl Ou <shunhsingou@google.com>
Maintainer: Daniel Carvalho <odanrc@yahoo.com.br>
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>
This translation generator is returned by the new version of the
TranslateFunctional method which translates a region rather than a
single address. That method is currently virtual with a default
implementation which is not overloaded, but the plan is for the other
MMUs to override that method and inject their own page size minimally.
In the future, the MMUTranslationGen class and the implementations in
the MMUs may be updated so that they can, for instance, handle varying
page sizes across a single translation.
Change-Id: I39479f0f0e8150fc6e3e1a7097a0c8bd8d22d4e0
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/50759
Reviewed-by: Gabe Black <gabe.black@gmail.com>
Maintainer: Gabe Black <gabe.black@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Turn the functions within it into virtual methods on the ISA classes.
Eliminate the implementation in MIPS, which was just copy pasted from
Alpha long ago. Fix some minor style issues in ARM. Remove templating.
Switch from using an "XC" type parameter to using the ThreadContext *
installed in all ISA classes.
The ARM version of these functions actually depend on the ExecContext
delaying writes to MiscRegs to work correctly. More insiduously than
that, they also depend on the conicidental ThreadContext like
availability of certain functions like contextId and getCpuPtr which
come from the class which happened to implement the type passed into XC.
To accomodate that, those functions need both a real ThreadContext, and
another object which is either an ExecContext or a ThreadContext
depending on how the method is called.
Jira Issue: https://gem5.atlassian.net/browse/GEM5-1053
Change-Id: I68f95f7283f831776ba76bc5481bfffd18211bc4
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/50087
Maintainer: Gabe Black <gabe.black@gmail.com>
Reviewed-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
Tested-by: kokoro <noreply+kokoro@google.com>
The ISAs we support today mostly have a micropc, whether that's used
very heavily like on x86, or sparsely like on ARM, RISCV or SPARC. Only
MIPS and POWER don't currently use a micropc, and neither of those is
performance tuned to the point where adding some size to the PC object
should make a meaningful difference.
Because most ISAs already have a micropc anyway, and some minimal part
of managing the micropc has to be part of the guaranteed interface so
that the CPUs can work, it's a small step to make the micropc more
completely part of the base class.
This change also makes uReset part of the guaranteed interface so we can
get rid of an #if THE_ISA == in the minor CPU.
Jira Issue: https://gem5.atlassian.net/browse/GEM5-1060
Change-Id: Ide55a8feaee0bd5fff1d7ec05f95ad30a496b196
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/48704
Reviewed-by: Hoa Nguyen <hoanguyen@ucdavis.edu>
Maintainer: Gabe Black <gabe.black@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
It is possible from the MMU to traverse the entire hierarchy of
TLBs, starting from the DTB and ITB (generally speaking from the
first level) up to the last level via the nextLevel pointer. So
in theory no extra data should be stored in the BaseMMU.
This design makes some operations a bit more complex. For example
if we have a unified (I+D) L2, it will be pointed by both ITB and
DTB. If we want to invalidate all TLB entries, we should be
careful to not invalidate L2 twice, but if we simply follow the
next level pointer, we might do so. This is not a problem from
a functional perspective but alters the TLB statistics (a single
invalidation is recorded twice)
We then provide a different view of the set of TLBs in the system.
At the init phase we traverse the TLB hierarchy and we add every
TLB to the appropriate set. This makes invalidation (and any
operation targeting a specific kind of TLBs) easier.
JIRA: https://gem5.atlassian.net/browse/GEM5-790
Change-Id: Ieb833c2328e9daeaf50a32b79b970f77f3e874f7
Signed-off-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/48146
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Jason Lowe-Power <power.jg@gmail.com>
Reviewed-by: Andreas Sandberg <andreas.sandberg@arm.com>
Maintainer: Jason Lowe-Power <power.jg@gmail.com>
Maintainer: Andreas Sandberg <andreas.sandberg@arm.com>
The proxies are not used on the critical path, and it's usually implicit
whether they should be the FS or SE version.
Ideally in the future we won't need to worry about which version we need
to use, but the differences haven't quite been abstracted away, and
occasionally we need to decide between the two.
Change-Id: Idb363d6ddc681f7c1ad5e7aba69865f40aa30dc8
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/45907
Maintainer: Bobby R. Bruce <bbruce@ucdavis.edu>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
Apply the gem5 namespace to the codebase.
Some anonymous namespaces could theoretically be removed,
but since this change's main goal was to keep conflicts
at a minimum, it was decided not to modify much the
general shape of the files.
A few missing comments of the form "// namespace X" that
occurred before the newly added "} // namespace gem5"
have been added for consistency.
std out should not be included in the gem5 namespace, so
they weren't.
ProtoMessage has not been included in the gem5 namespace,
since I'm not familiar with how proto works.
Regarding the SystemC files, although they belong to gem5,
they actually perform integration between gem5 and SystemC;
therefore, it deserved its own separate namespace.
Files that are automatically generated have been included
in the gem5 namespace.
The .isa files currently are limited to a single namespace.
This limitation should be later removed to make it easier
to accomodate a better API.
Regarding the files in util, gem5:: was prepended where
suitable. Notice that this patch was tested as much as
possible given that most of these were already not
previously compiling.
Change-Id: Ia53d404ec79c46edaa98f654e23bc3b0e179fe2d
Signed-off-by: Daniel R. Carvalho <odanrc@yahoo.com.br>
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/46323
Maintainer: Bobby R. Bruce <bbruce@ucdavis.edu>
Reviewed-by: Bobby R. Bruce <bbruce@ucdavis.edu>
Reviewed-by: Matthew Poremba <matthew.poremba@amd.com>
Tested-by: kokoro <noreply+kokoro@google.com>
These had been templated on a type, and then the width of that type was
considered the amount the PC should advance when executing straight line
code. That type was MachInst, which was loosely the size of an
instruction, but was practically whatever sized data type was fed into
the decoder at a time.
Instead of tying this to a type, this change moves it over to be a
simple number. This avoids a level of indirection, and also further
decouples the type the decoder might use as input from the instruction
size.
Change-Id: I797876a33d27e759c7a6e23a658179201fabfa47
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/40176
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Gabe Black <gabe.black@gmail.com>
Maintainer: Bobby R. Bruce <bbruce@ucdavis.edu>
In this context, the decoder width is the number of bytes that are fed
into the decoder at once. This is frequently the same as the size of an
instruction, but in instructions with occasionally variable instruction
sizes (ARM, RISCV), or extremely variable instruction sizes (x86) there
may be no relation.
Rather than determining the amount of data to feed to the decoder based
on a MachInst type defined by each ISA, this new interface adds some new
properties to the base InstDecoder class each arch specific decoder
inherits from. These are the size of the incoming buffer, a pointer to
wherever that data should end up, and a mask for masking a PC value so
it aligns with the instruction size.
These values are filled in by a templated InstDecoder constructor which
is templated based on what would have historically been the MachInst
type.
Because the "moreBytes" method would historically accept a parameter of
type MachInst, this parameter has also been eliminated. Now, the
decoder's parent object should use the pointer and size values to fill
in the buffer moreBytes reads. Then when moreBytes is called, it just
uses the buffer without having to show what its type is externally.
Change-Id: I0642cdb6a61e152441ca4ce47d748639175cda90
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/40175
Reviewed-by: Gabe Black <gabe.black@gmail.com>
Maintainer: Gabe Black <gabe.black@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
The arch/generic/types.hh header includes some more complicated types
which in turn bring in more dependencies, adding baggage when other code
only needs the simple RegIndex or ElemIndex types. Also the RegVal type
alias is already in base/types.hh. It doesn't really make sense to have
RegVal in one header and RegIndex in another.
Change-Id: I1360652598b5fa59e0632b1ee0e0535ace2ba563
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/42966
Maintainer: Gabe Black <gabe.black@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Bobby R. Bruce <bbruce@ucdavis.edu>
