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>
The O3CPU, which supports transactional memory (HTM), is using
the inHtmTransactionalState and getHtmCheckpointPtr methods
to check if we are in the middle of a transaction and return
false or a nullptr if that's not the case.
We need to avoid aborting simulation (panic) when those methods are
called in the O3CPU + Checker simulation.
This patch is providing the minimal support to re-enable O3 + Checker
runs and it is not providing HTM support in the CheckerCPU (meaning, we
won't be able to use the Checker in a transactional simulation)
Signed-off-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
Change-Id: I7f71d5290c53b0402763d69f137ecaa1208253fb
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/46624
Reviewed-by: Jason Lowe-Power <power.jg@gmail.com>
Reviewed-by: Richard Cooper <richard.cooper@arm.com>
Maintainer: Jason Lowe-Power <power.jg@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Add stat in o3 model to track the latency of load instructions
(no SWP) between issue and waking up of dependent instructions.
The max latency tracked in the stat histogram is curently
fixed to 299 and should be changed if someone wants to
track more precisely high latency memory acess.
Change-Id: I5973a4aa279bcc388d1a32b706c2e4f5e3f25e75
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/46679
Reviewed-by: Jason Lowe-Power <power.jg@gmail.com>
Maintainer: Jason Lowe-Power <power.jg@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
On configs with renameWidth > dispatchWidth, on receiving
renameWidth number of only squashed instructions:
the dispatch stage will not be able to treat all instructions.
Some squashed instructions will then remain in the 'inst' buffer
after the dispatch stage.
'validInstsFromRename' function don't take into account squashed
instructions, thus the remaining squashed instructions are
not moved to the skid buffer.
The cycle after, the assert in sortInsts will trigger(on debug mode)
because the 'inst' buffer is not empty.
Change-Id: I1a1ed5a7f040041363bd1b2c7bf10c85eb7febaf
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/46600
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 fixes the unlikely but possible following case :
- Assume cond/uncond direct branch A jumping to next branch (PC + 4 in ARM). From
the point of view of the PCState object, the instruction is not branching
(PCState::branching() will return false since it tests whether nextPC != PC + 4 for ARM).
This gets cached in the BTB.
- Assume another cond branch B that is predicted taken but uses the PCState object of the
first branch A from the BTB due to a partial tag match (BTB is not fully tagged).
- At decode, the mistarget will be detected because the target given by the BTB does
not match the target encoded in the instruction B. However, to determine what PC to send to
fetch, decode looks at inst->pcState().branching(), which returns false because the PCState
object has PC X, and nextPC X + 4 (ARM case). Therefore, Decode sends the
fallthrough address of branch B, despite it being predicted taken. If the prediction is
correct, Exec will not realize that the target is wrong since it is the Decode stage's job.
Jira Issue: https://gem5.atlassian.net/browse/GEM5-947
Change-Id: Ia3b960bb660bdfd3c348988d6532735fa3268990
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/46260
Reviewed-by: Nathanael Premillieu <nathanael.premillieu@huawei.com>
Reviewed-by: Jason Lowe-Power <power.jg@gmail.com>
Maintainer: Jason Lowe-Power <power.jg@gmail.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>
As part of recent decisions regarding namespace
naming conventions, all namespaces will be changed
to snake case.
::ProbePoints became ::probing.
"probing" was chosen over "probe_points" because the
namespace contains more than solely probe points; it
contains all classes related to the act of probing.
Change-Id: I44567974a521707593739a2bd5933391803e5b51
Signed-off-by: Daniel R. Carvalho <odanrc@yahoo.com.br>
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/45412
Maintainer: Jason Lowe-Power <power.jg@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Hoa Nguyen <hoanguyen@ucdavis.edu>
The only thing brought in by arch/types.hh is TheISA::PCState. Instead
of having the other types around where they could be used accidentally,
and to make it more obvious what's being exported, this change splits
PCState out into a new switching header called arch/pcstate.hh. The
original arch/types.hh is no longer a switching header, and includes
pcstate.hh.
Change-Id: I8dfd298349e4565f316f7b9a028703289ada6010
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/40177
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Gabe Black <gabe.black@gmail.com>
Maintainer: Gabe Black <gabe.black@gmail.com>
There are two user visible effects of this change. First, all of the
threads for a particular workload are moved under a single GDB instance.
The GDB session can see all the threads at once, and can let you move
between them as you want.
Second, since there is a GDB instance per workload and not per CPU, the
wait_for_gdb parameter was moved to the workload.
Change-Id: I510410c3cbb56e445b0fbb1def94c769d3a7b2e3
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/44617
Reviewed-by: Daniel Carvalho <odanrc@yahoo.com.br>
Maintainer: Gabe Black <gabe.black@gmail.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.
sim_clock::Float became sim_clock::as_float.
"as_float" was chosen because "float" is a reserved
keywords, and this namespace acts as a selector of
how to read the internal variables. Another
possibility to resolve this would be to remove the
namespaces "Float" and "Int" and use unions instead.
Change-Id: I7b3d9c6e9ab547493d5596c7eda080a25509a730
Signed-off-by: Daniel R. Carvalho <odanrc@yahoo.com.br>
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/45435
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Hoa Nguyen <hoanguyen@ucdavis.edu>
Maintainer: Gabe Black <gabe.black@gmail.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>
This can be used to send a functional packet from the perspective of a
thread context. Currently this will not consider targets within the CPU
like the local APIC on x86. The default implementation sends a packet
using the port on the way out of the CPU.
Change-Id: Idb311e156a416ad51b585794c1e9fa75711d61f1
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/45861
Maintainer: Gabe Black <gabe.black@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Yu-hsin Wang <yuhsingw@google.com>
Reviewed-by: Jason Lowe-Power <power.jg@gmail.com>
