This is removing the cached boolean variables from the ISA class.
The ISA is now using a release object.
It is importing it from the ArmSystem in case of a FS simulation,
and it is using its own ArmRelease object in SE mode
This allows us to add/remove SE extensions from python, rather than
hardcoding them in the ISA constructor (in case of SE)
Change-Id: I2b0b2f113e7bb9e28ac86bf2139413e2a71eeb01
Signed-off-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/51012
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Andreas Sandberg <andreas.sandberg@arm.com>
Maintainer: Andreas Sandberg <andreas.sandberg@arm.com>
The constructor of the LoadQueue and StoreQueue were adding
an additional entry compared to the given configuration.
The removed comment was saying that this additional entry was
used as a dummy entry.
This is not necessary anymore with the current structure.
It was even leading to incorrect behavior as a loadQueue
could have one more outstanding load than specified
by the configuration.
Valgrind does not spot any illegal access.
Change-Id: I41507d003e4d55e91215e21f57119af7b3e4d465
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/50732
Reviewed-by: Bobby R. Bruce <bbruce@ucdavis.edu>
Maintainer: Bobby R. Bruce <bbruce@ucdavis.edu>
Tested-by: kokoro <noreply+kokoro@google.com>
This parameter is used to figure out if two addresses are on the same or
different pages, and could be used to find what page they were on and
the page offset, although it doesn't look like the later two are
actually used.
This value could possibly come from the TLB parameter attached to the
prefetcher, but making it explicit makes these more symmetric with the
Ruby prefetcher, and reduces the complexity of the TLB implementation.
Change-Id: I6921943c49af19971b84225ecfd1127304363426
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/50352
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Andreas Sandberg <andreas.sandberg@arm.com>
Maintainer: Andreas Sandberg <andreas.sandberg@arm.com>
This made it skip over 70 pages to be "what it was before" my page table
changes. I'm not sure what changes this is referring to, and the class
which manages page tables in the guest memory uses the allocPhysPages
method to allocate its memory and would cooperate with anything else
using this mechanism without having to have special accomodation.
I removed this hack and hello world seems to work fine, but there may be
some other test case which exposes some problems.
Change-Id: I16e0d8835452df9c3e79738a1eed05b4cc9372b7
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/50349
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Matthew Poremba <matthew.poremba@amd.com>
Maintainer: Gabe Black <gabe.black@gmail.com>
LULESH is a popular GPU HPC application that acts as a good test
for several memory and compute patterns. Thus, including it in
the weekly regressions will help verify correctness and
functionality for code that affects the GPU. The default LULESH
input runs 10 iterations and takes 3-4 hours. Hence, it is not
appropriate for nightly regressions.
Change-Id: Ic1b73ab32fdd5cb1b973f2676b272adb91b2a98e
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/50952
Maintainer: Matt Sinclair <mattdsinclair@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Bobby R. Bruce <bbruce@ucdavis.edu>
HeteroSync does a good job of testing the GPU memory system and
atomics support, without requiring a long runtime. Thus, this
commit adds a mutex and barrier test from HeteroSync to the
nightly regression to ensure these components are tested.
Change-Id: I65998a0a63d41dd3ba165c3a000cee7e42e9034a
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/50951
Maintainer: Matt Sinclair <mattdsinclair@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Bobby R. Bruce <bbruce@ucdavis.edu>
In the MemPool object, the idea of a limit of the pool (largest page)
and the total number of pages were conflated, as was the page number of
the next "free" page and the total number of pages allocated. Both of
those would only be equivalent if the memory pool starts at address
zero, which is not generally true and could be true for at most one pool
at a time even when it is occasionally true.
Instead, this change fixes up MemPool to keep tree values, a starting
page number, the page number of the next free page, and the total number
of pages in the pool, both allocated and unallocated.
With those three values, we can accurately report the number of
allocated pages (not just the number of pages of any kind below the next
free one), the total number of free pages, and the total number of pages
in general (not the largest numbered page in the pool).
The value serialized by the System class was adjusted so that it will
stay compatible with previous checkpoints. The value unserialized by the
system class is passed to the MemPool as a limit, which has not changed
and so doesn't need to be updated. It gets translated into the total
number of pages in the MemPool constructor.
Change-Id: I8268ef410b41bf757df9ee5585ec2f6b0d8499e1
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/50687
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>
Similar to the flags issue in the previous patch, the FlatGlobal flag
does not exist. Change all of the flat instructions to use the same
issue logic as GCN3. A helper function is also added as loads and stores
use the same interface. The helper function can be more easily updated
to support global and scratch subtypes of flat instructions.
Change-Id: I394f1d4c59b029201fe2f6075c9dedb3a37dbe31
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/50827
Reviewed-by: Matt Sinclair <mattdsinclair@gmail.com>
Reviewed-by: Kyle Roarty <kyleroarty1716@gmail.com>
Maintainer: Matt Sinclair <mattdsinclair@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
The instructions file seems to be assuming a newer pipeline which is not
released. The flags are therefore not set in Vega as the newer pipeline
infers them. This adds back flags for MemoryRef instructions, fixes
waitcnt and removes CondBranch which was not checked and changed to
Branch.
This also removeds unused Cac flags and fixes the casing for ReadsEXEC
and WritesEXEC. The remaining flags are not used at all by the pipeline
and are removed to avoid confusion as to whether these are needed for
GCN3 or not.
Change-Id: I976cbd407a466e8ad77c84dbdc29082f49e28f3b
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/47102
Reviewed-by: Kyle Roarty <kyleroarty1716@gmail.com>
Reviewed-by: Matt Sinclair <mattdsinclair@gmail.com>
Maintainer: Matthew Poremba <matthew.poremba@amd.com>
Maintainer: Matt Sinclair <mattdsinclair@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
It's really a part of the build system and not part of gem5, and so it
should probably live outside of the main tree. It would be confusing to
have a bunch of python scripts which don't end up inside gem5 alongside
a bunch of ones that do in src/python.
The directory is called build_tools instead of build so it doesn't get
confused with an actual build output directory.
Change-Id: Ie12475a15517508dc2044f0ca4db71a601b7ab6d
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/49393
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Gabe Black <gabe.black@gmail.com>
Maintainer: Gabe Black <gabe.black@gmail.com>
The new c++ wrapper is called gem5py, and will run any python script
using gem5's embedded python interpreter. The "marshal" functionality is
split out into a separate python script gem5py can run.
The command line for gem5py should look like this:
gem5py ${SCRIPT TO RUN} ${ARGS TO THE SCRIPT}
So, for instance, to marshal a file called foo.py, the command line
might look like this:
gem5py python/marshal.py foo.py
Also, this change reorders the sources for the python embedding action
and limits the max_sources for Transform() to 1, so that it just shows
the python file being embedded and not gem5py or the marshal.py script.
Those are still sources so dependency tracking works correctly, but they
are also implied and just add visual noise to the build output.
Change-Id: I7ae6bd114973ae44c3b634884b6dafc6577e0788
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/49392
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Gabe Black <gabe.black@gmail.com>
Maintainer: Gabe Black <gabe.black@gmail.com>
Remove references to alpha and SWIG. Change the list of configs to be a
list of configs and not ISAs even though they are frequently named after
the ISA, say that the options are in build_opts, add in missing top
level directories, update and generalize the description of full system,
re-wrap some text.
Change-Id: Id2fb9323dcb9d8bf8e86c78fb5e9aa6afed1c5b8
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/50755
Reviewed-by: Gabe Black <gabe.black@gmail.com>
Reviewed-by: Jason Lowe-Power <power.jg@gmail.com>
Maintainer: Gabe Black <gabe.black@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
In the gcn-gpu image, rocBLAS wasn't able to be installed. This was
due to us not installing rocm-cmake, as rocBLAS is dependent on it
and will download the most recent version of rocm-cmake if it
isn't installed. The most recent version of rocm-cmake wasn't
compatible with the version of ROCm we're using.
This patch installs rocm-cmake before building and installing
rocBLAS instead of after.
Change-Id: Iaaa34d5e0d6594fddd0d1a7d147f43405163ca89
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/50847
Reviewed-by: Matt Sinclair <mattdsinclair@gmail.com>
Reviewed-by: Bobby R. Bruce <bbruce@ucdavis.edu>
Maintainer: Matt Sinclair <mattdsinclair@gmail.com>
Maintainer: Bobby R. Bruce <bbruce@ucdavis.edu>
Tested-by: kokoro <noreply+kokoro@google.com>
