Change the type passed to updateBranchData in execute to be a reference,
and replace the nullptr being passed in from Execute::evaluate() with
the current thread's pc. We could use any generic PC instead which might
be slightly faster, but there is likely not a significant difference
and this is a lot easier.
Change-Id: I306ca53b33997f76217c61123e5922df612005f9
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/53584
Maintainer: Gabe Black <gabe.black@gmail.com>
Reviewed-by: Bobby Bruce <bbruce@ucdavis.edu>
Tested-by: kokoro <noreply+kokoro@google.com>
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>
This allows us to set a high number of threads for gem5 compilation
tasks, and a lower number of threads for running gem5. The latter is
more memory intensive and, therefore, we cannot always use the maximum
number of threads in a system.
Change-Id: I699d9f74b21d31841bf31e3589d323b007cb4601
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/53483
Reviewed-by: Jason Lowe-Power <power.jg@gmail.com>
Maintainer: Jason Lowe-Power <power.jg@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Currently, the installation instructions are for installing
SST-core and SST-elements version 11.0.0. This change updates
instructions to the current SST-core and SST-element version,
11.1.0.
This change also reflects that manually downloading the
`bbl-busybox-boot-exit` is no longer necessary as the example
gem5 config will download automatically.
Change-Id: I616ca38316213dcbd71b6eab121b5ac89eed1962
Signed-off-by: Hoa Nguyen <hoanguyen@ucdavis.edu>
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/53463
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 method is responsible for comparing gem5's state against the state
of the real process. When checking the value of NPC, it accessed the
value of nnpc() by calling pc.nnpc(), but did not actually update regVal
with it, so the comparison was between the value from the real process
and npc().
It's mildly confusing that nnpc is compared against npc, and npc against
pc, but that's because of what the state looks like in the real process
when single stepping through it with ptrace.
You can actually see where this bug was introduced if you look at the
change which created the PCState types originally. There, you can see
how regVal was set using a method of the ThreadContext, but after that
change the value is only accessed and not actually used.
Change-Id: I0f0101db5f807640b8d25fef6448081d9cfa0213
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/53363
Reviewed-by: Daniel Carvalho <odanrc@yahoo.com.br>
Reviewed-by: Boris Shingarov <shingarov@labware.com>
Maintainer: Gabe Black <gabe.black@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
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>
As described in a comment in the base KVM CPU, there needs to be a way
to set the next PC of a PCState object to the actual current PC. Since
this is the only place that sort of operation is needed and it's a bit
of a hack to get around a quirk of calling pseudo instructions in a KVM
CPU, we can support it by adding a virtual method for it which is
implemented by the ISA specific subclasses of the KVM CPU.
Change-Id: Idf390e9c4ffa7398cd08e76846c61cb6da754dce
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/52059
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Daniel Carvalho <odanrc@yahoo.com.br>
Maintainer: Gabe Black <gabe.black@gmail.com>
The default value of IPredEntry::tag is 0, and if we just blindly
compare the tag we're looking for against this value, we might run into
cases where we match against an uninitialized IPredEntry. In that case,
IPredEntry::target has not been initialized, and if we try to use it in
lookup(...) we'll dereference nullptr and segfault.
To avoid that, we can just add one additional check that makes sure that
not only does the tag of the IPredEntry match, but also that the value
of target is not null, and so the IPredEntry *actually* has tag 0 and
isn't just uninitialized.
Change-Id: I892d0df7c00a0a4cd3ca215fe3a7586ddbca9395
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/53403
Maintainer: Gabe Black <gabe.black@gmail.com>
Reviewed-by: Jason Lowe-Power <power.jg@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Without this verbose flag, there is no information output on the tests
currently running. Output is only given on the pass/fail status of a
test after completion. This is unhelpful if the tests fail due to a
timeout (e.g., a test has stalled).
The '-vv' verbose flags sets up the TestLib package to output when a
test has started execution. This information can help in figuring out
which test caused a timeout event to occur.
Change-Id: I14e6752d40a7c8d7189211584073ba79c88ed7d5
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/53305
Maintainer: Bobby R. Bruce <bbruce@ucdavis.edu>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Jason Lowe-Power <power.jg@gmail.com>
Enable a gem5 system to be an SST::Component.
This change includes,
- SST::gem5Component: responsible for,
- initializing the Python environment for gem5
- instantiating gem5 SimObjects
- connecting SST::SSTResponderSubComponent to
gem5::OutgoingRequestBridge
- hanlding the gem5 event queue (no thread-synchronization)
- handling executing gem5 events
- SST::SSTResponderSubComponent: responsible for,
- receiving gem5 requests and sending the requests to
memory.
- sending responses to the corresponding
gem5::OutgoingRequestBridge.
- SST::SSTResponder: owned by SSTResponderSubComponent, the
actual actor that sends gem5's requests to memory.
- gem5::OutgoingRequestBridge: receives the requests from
gem5 and sends them to SST. This SimObject allows the initialization
requests to be cached and the receiver could query the
initialization data later on.
- gem5::SSTResponderInterface: the interface specifying how SST
communicates with gem5.
- A working example of a gem5/SST setup.
More information is available at ext/sst/README.md.
For installation instructions, please refer to ext/sst/INSTALL.md.
Change-Id: I6b81260ef825415bcfe72b8a078854f4c94de782
Signed-off-by: Hoa Nguyen <hoanguyen@ucdavis.edu>
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/50468
Reviewed-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
Reviewed-by: Bobby R. Bruce <bbruce@ucdavis.edu>
Maintainer: Giacomo Travaglini <giacomo.travaglini@arm.com>
Tested-by: kokoro <noreply+kokoro@google.com>
