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>
The nullStaticInstPtr was low overhead, but the nopStaticInstPtr needed
an actual StaticInst implementation it could point to, and that brought
with it some (minor) additional dependencies. Specifically, the
implementation of advancePC needs the definition of TheISA::PCState,
while all other signatures/impementations in StaticInst are already
passing around that type by reference or could be made to, reducing
dependencies further.
Change-Id: I9ac6a6e5a3106858ea1fc727648f61dc39738a59
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/42968
Reviewed-by: Gabe Black <gabe.black@gmail.com>
Maintainer: Gabe Black <gabe.black@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
There is no way to make this sort of template work with more than one
ISA at a time, and it's also more complex than it needs to be,
particularly since the methods within it are never used in performance
critical code. Using virtual functions is also simpler and uses less
code.
Change-Id: I0baa1a651fa656420f6f90776572f8700a6d7cab
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/40106
Reviewed-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
Maintainer: Giacomo Travaglini <giacomo.travaglini@arm.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Added takeover methods for PMA Checker and RiscvTLB to ensure
that checkpoint restoration works. Also added logic in PLIC
to prevent posting interrupts to a CPU that has yet to complete
the current interrupt. PLIC's behaviour when a CPU claims another
interrupt before completion is also changed. Now PLIC will return
the uncompleted interrupt ID instead of return 0. This behaviour
is not documented in the specs but is designed this way to avoid
issues from CPU side (especially MinorCPU).
Change-Id: I68eaaf56d2c4d76cc1e0a1e2160f5abe184c2cd5
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/41933
Maintainer: Bobby R. Bruce <bbruce@ucdavis.edu>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Ayaz Akram <yazakram@ucdavis.edu>
These currently only hold the number of registers in a particular class,
but can be extended in the future to hold other information about each
class. The ISA class holds a vector of descriptors which other parts of
gem5 can retrieve to set up storage for each class, etc.
Currently, the RegClass enum is used to explicitly index into the vector
of descriptors to get information about a particular class. Once enough
information is stored in the descriptors, the other parts of gem5 should
be able to set up for each register class generically, and the ISAs will
be able to leave out or create new register classes without having to
set up global plumbing for it.
The more immediate benefit is that this should (mostly) parameterize
away the ISA register constants to break another TheISA style
dependency. Currently a global set of descriptors are set up in the
BaseISA class using the old TheISA constants, but it should be easy to
break those out and make the ISAs set up their own descriptors. That
will bring arch/registers.hh significantly closer to being eliminated.
Change-Id: I6d6d1256288f880391246b71045482a4a03c4198
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/41733
Reviewed-by: Gabe Black <gabe.black@gmail.com>
Maintainer: Gabe Black <gabe.black@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Override ParseParam<>::parse and ShowParam<>::parse directly. This will
allow using a different format for serializing and displaying registers.
Also get rid of the print() methods. When any cprintf based mechanism is
used (like DPRINTF), the underlying mechanism will use << to output the
value. Since we already override <<, there's no reason to wrap that in a
method which calls csprintf which calls << anyway.
Change-Id: Id65b9a657507f2f2cdf9673fd961cfeb0590f48c
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/41994
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
Maintainer: Giacomo Travaglini <giacomo.travaglini@arm.com>
The patch is using the newly defined PARAMS macro to replace
custom params() getters in derived class.
The patch is also removing redundant _params:
Instead of creating yet another _params field, SimObject descendants
should use params() to expose the real type of SimObject::_params they
already have.
Change-Id: I43394cebb9661fe747bdbb332236f0f0181b3dba
Signed-off-by: Alexander Klimov <Alexander.Klimov@arm.com>
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/39900
Reviewed-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
Maintainer: Giacomo Travaglini <giacomo.travaglini@arm.com>
Tested-by: kokoro <noreply+kokoro@google.com>
The event in KVM x86 SE mode plays double duty, triggering a system call
or a page fault depending on where it's called from (the system call
handler vs page fault handler).
This means we can eliminate the page fault gem5 op and the
pseudo_inst.hh switching header file.
This change touches a lot of things, but there wasn't really a good
place to split it up which still made sense and was consistent and
functional.
Change-Id: Ic414829917bcbd421893aa6c89d78273e4926b78
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/34165
Reviewed-by: Gabe Black <gabe.black@gmail.com>
Reviewed-by: Alexandru Duțu <alexandru.dutu@amd.com>
Maintainer: Gabe Black <gabe.black@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
The create() method on Params structs usually instantiate SimObjects
using a constructor which takes the Params struct as a parameter
somehow. There has been a lot of needless variation in how that was
done, making it annoying to pass Params down to base classes. Some of
the different forms were:
const Params &
Params &
Params *
const Params *
Params const*
This change goes through and fixes up every constructor and every
create() method to use the const Params & form. We use a reference
because the Params struct should never be null. We use const because
neither the create method nor the consuming object should modify the
record of the parameters as they came in from the config. That would
make consuming them not idempotent, and make it impossible to tell what
the actual simulation configuration was since it would change from any
user visible form (config script, config.ini, dot pdf output).
Change-Id: I77453cba52fdcfd5f4eec92dfb0bddb5a9945f31
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/35938
Reviewed-by: Gabe Black <gabeblack@google.com>
Reviewed-by: Daniel Carvalho <odanrc@yahoo.com.br>
Maintainer: Gabe Black <gabeblack@google.com>
Tested-by: kokoro <noreply+kokoro@google.com>
With some exceptions (in arm/x86) the standard memory read/write interface
for instructions relies upon the helper functions in
src/arch/generic/memhelpers.hh
which wrap the ExecContext interface.
(readMem, writeMem...)
Those helpers rely on the source/destination data to be provided (as
expected) but not on the size of the transaction. The latter gets
evaluated via the host size of the source/destination data
(sizeof(MemT)).
For this reason some instructions, which are instead using an
incompatible MemT data (as an example, a SIMD operation loading data in
an array of integers), make direct use of the ExecContext interface,
which is simply requesting for a pointer and a number of bytes.
Some other instructions are using the ExecContext interface since the
helpers do not accept a byteEnable argument.
This patch is adding some helpers to address these issues. The idea is
to deprecate direct usage of the ExecContext APIs.
These new wrappers do not work with the type detection mechanism
to evaluate the number of bytes we are accessing.
JIRA: https://gem5.atlassian.net/browse/GEM5-196
Change-Id: I5b822d278bdf325a68a01aa1861b6487c6628245
Signed-off-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/23527
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Gabe Black <gabeblack@google.com>
Reviewed-by: Daniel Carvalho <odanrc@yahoo.com.br>
Maintainer: Gabe Black <gabeblack@google.com>
