Currently, compiling CheckerCPU uses the dyn_inst.hh header from
O3CPU. However, including this header is not required and it
causes gem5 failed to build when O3CPU is not part of CPU_MODELS.
This change also involves moving the the dependency on
src/cpu/o3/dyn_inst.hh to src/cpu/o3/cpu.cc and src/cpu/lsq_unit.cc,
which previously includes src/cpu/o3/dyn_inst.hh implicitly through
src/cpu/checker/cpu.hh.
JIRA: https://gem5.atlassian.net/browse/GEM5-1025
Change-Id: I7664cd4b9591bf0a4635338fff576cb5f5cbfa10
Signed-off-by: Hoa Nguyen <hoanguyen@ucdavis.edu>
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/48079
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>
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>
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>
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>
