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>
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>
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 CpuModel class looks like it was originally intended to hold a lot
more information that it does now, which is just the name of a CPU, and
whether it should be enabled by default. All the built in configs in
build_opts already explicitly list a set of CPUs, and CPUs should not,
generally speaking, be enabled by default, since they almost always need
to be specifically supported by an ISA. This is mutual, since usually
ISAs definitions are not quite correct or complete, and this is often
exposed by plugging them into different, and/or more complex CPU models
which stress those short comings.
This change drops the idea of a "default" CPU, and since the only thing
being tracked at this point is a list of CPUs, it turns CpuModel() into
a simple function which adds a name to a set of supported CPUs.
Change-Id: Id7475d5dc8548802b5253f79839da8c76ef4d165
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/48963
Reviewed-by: Hoa Nguyen <hoanguyen@ucdavis.edu>
Reviewed-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
Maintainer: Gabe Black <gabe.black@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Instruction fetch should not commence if there already is an
instruction-count event in the queue.
The most conspicuous scenario where this leads to obvious breakage,
is guest debugging. Imagine the first bytes in the program pointed to
by _start are invalid instruction encoding, and we pass the --wait-gdb
flag. Then in GDB we set $pc to point to valid instructions, and we
"continue". gem5 will abort with "invalid instruction".
This is not how real targets behave: neither software- (e.g. ptrace)
based debuggers, nor low-level (e.g. OpenOCD or XMD connected over
JTAG to debug early initialization code eg when the MMU has not been
switched on yet, etc.) Fetching should start from where $pc was set
to. This patch tries to model this behavior.
Change-Id: Ibce6fdbbb082edf1073ae96745bc7867878f99ca
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/27587
Reviewed-by: Jason Lowe-Power <power.jg@gmail.com>
Maintainer: Jason Lowe-Power <power.jg@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.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>
As part of recent decisions regarding namespace
naming conventions, all namespaces will be changed
to snake case.
::Stats became ::statistics.
"statistics" was chosen over "stats" to avoid generating
conflicts with the already existing variables (there are
way too many "stats" in the codebase), which would make
this patch even more disturbing for the users.
Change-Id: If877b12d7dac356f86e3b3d941bf7558a4fd8719
Signed-off-by: Daniel R. Carvalho <odanrc@yahoo.com.br>
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/45421
Reviewed-by: Jason Lowe-Power <power.jg@gmail.com>
Maintainer: Jason Lowe-Power <power.jg@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
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>
There is a design which has been put forward which eliminates the idea
of a zero register entirely, but in the mean time, to get rid of one
more ISA specific constant, this change moves the ZeroReg constant into
the RegClassInfo class, specifically the IntRegClass instance which is
published by each ISA.
When the idea of zero registers has been eliminated entirely from
non ISA specific code, this and the existing machinery can be
eliminated.
Change-Id: I4302a53220dd5ff6b9b47ecc765bddc6698310ca
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/42685
Reviewed-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
Maintainer: Giacomo Travaglini <giacomo.travaglini@arm.com>
Tested-by: kokoro <noreply+kokoro@google.com>
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>
The systemc dir was not included in this fix.
First it was identified that there were only occurrences
at 0, 1, and 2 levels of indentation (and 2 of 2 spaces,
1 of 3 spaces and 2 of 12 spaces), using:
grep -nrE --exclude-dir=systemc \
"^ *enum [A-Za-z].* {$" src/
Then the following commands were run to replace:
<indent level>enum X ... {
by:
<indent level>enum X ...
<indent level>{
Level 0:
grep -nrl --exclude-dir=systemc \
"^enum [A-Za-z].* {$" src/ | \
xargs sed -Ei \
's/^enum ([A-Za-z].*) \{$/enum \1\n\{/g'
Level 1:
grep -nrl --exclude-dir=systemc \
"^ enum [A-Za-z].* {$" src/ | \
xargs sed -Ei \
's/^ enum ([A-Za-z].*) \{$/ enum \1\n \{/g'
and so on.
Change-Id: Ib186cf379049098ceaec20dfe4d1edcedd5f940d
Signed-off-by: Daniel R. Carvalho <odanrc@yahoo.com.br>
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/43326
Reviewed-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
Reviewed-by: Gabe Black <gabe.black@gmail.com>
Maintainer: Giacomo Travaglini <giacomo.travaglini@arm.com>
Tested-by: kokoro <noreply+kokoro@google.com>
In most ISAs except MIPS and Power, this was implemented as
inst->advancePC(). It works just fine to call this function all the
time, but the idea had originally been that for ISAs which could simply
advance the PC using the PC itself, they could save the virtual function
call. Since the only ISAs which could skip the call were MIPS and Power,
and neither is at the point where that level of performance tuning
matters, this function can be collapsed with little downside.
If this turns out to be a performance bottleneck in the future, the way
the PC is managed could be revisited to see if we can factor out this
trip to the instruction object in the first place.
Change-Id: I533d1ad316e5c936466c529b7f1238a9ab87bd1c
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/39335
Maintainer: Gabe Black <gabe.black@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
Reviewed-by: Alex Dutu <alexandru.dutu@amd.com>
The systemc dir was not included in this fix.
First it was identified that there were only occurrences
at 0, 1, 2 and 3 levels of indentation (and a single
occurrence of 2 and 3 spaces), using:
grep -nrE --exclude-dir=systemc \
"^ *struct [A-Za-z].* {$" src/
Then the following commands were run to replace:
<indent level>struct X ... {
by:
<indent level>struct X ...
<indent level>{
Level 0:
grep -nrl --exclude-dir=systemc
"^struct [A-Za-z].* {$" src/ | \
xargs sed -Ei \
's/^struct ([A-Za-z].*) \{$/struct \1\n\{/g'
Level 1:
grep -nrl --exclude-dir=systemc \
"^ struct [A-Za-z].* {$" src/ | \
xargs sed -Ei \
's/^ struct ([A-Za-z].*) \{$/ struct \1\n \{/g'
and so on.
Change-Id: I362ef58c86912dabdd272c7debb8d25d587cd455
Signed-off-by: Daniel R. Carvalho <odanrc@yahoo.com.br>
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/39017
Reviewed-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
Maintainer: Giacomo Travaglini <giacomo.travaglini@arm.com>
Tested-by: kokoro <noreply+kokoro@google.com>
This DPRINTF accesses the ExtMachInst typed machInst member of the
StaticInst class, and so is ISA dependent. Move the DPRINTF to where the
instructions are actually decoded where that type doesn't have to be
disambiguated.
Also, this change makes this DPRINTF more accurate, since microops are
not really "decoded" when they are extracted from a macroop. The process
of unpacking them to feed into the rest of the CPU should be fairly
trivial, so really they're just being retrieved. With the DPRINTF in
this new position, it will only trigger when an instruction is actually
decoded from memory.
Change-Id: I14145165b93bb004057a729fa7909cd2d3d34d29
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/40099
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 was mostly not used to begin with, but also when it was used, it
would obscure places where there were types, functions, etc, which were
switched between ISAs at compile time, and which would need to be
cleaned up to allow more than one ISA at a time.
Change-Id: Ieb372feff91b7e946b477fb78e54bcd0c2138966
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/39655
Reviewed-by: Bobby R. Bruce <bbruce@ucdavis.edu>
Reviewed-by: Daniel Carvalho <odanrc@yahoo.com.br>
Maintainer: Bobby R. Bruce <bbruce@ucdavis.edu>
Tested-by: kokoro <noreply+kokoro@google.com>
