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>
Add a unit test for sim/serialize.hh.
==Bugs==
arrayParamIn cannot parse strings with spaces. Since spaces
are used as delimiters, strings containing spaces are parsed
as multiple entries of the array. The test that checks for
this has been disabled.
==Unexpected Behavior==
Serialization has an unexpected behavior when returning to
previous scopes. For example,
...
SCS scs(cpt, "S1")
paramOut(cpt, "param1", integer1)
{
SCS scs_2(cpt, "S2")
paramOut(cpt, "param2", integer2)
}
paramOut(cpt, "param3", integer3)
will generate the output:
...
[S1]
param1=1
[S2]
param2=2
param3=3
But the user might expect:
...
[S1]
param1=1
[S2]
param2=2
[S1]
param3=3
==Incovenient Behavior==
arrayParamIn with a std::array parameter is slightly
incovenient, since the raw data pointer must be extracted.
It may be worth it to add a template specialization.
==Not Tested==
paramInImpl is not being directly tested because it should
not be used as an external API - paramIn and optParamIn
should be used instead.
arrayParamIn with an InsertIterator parameter is not being
directly tested because the other versions should be used
instead.
Change-Id: If0c8f045aa317790d5fcb32e48629b113b62efc5
Signed-off-by: Daniel R. Carvalho <odanrc@yahoo.com.br>
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/41337
Reviewed-by: Bobby R. Bruce <bbruce@ucdavis.edu>
Maintainer: Bobby R. Bruce <bbruce@ucdavis.edu>
Tested-by: kokoro <noreply+kokoro@google.com>
Version 0.11 was actually the first version of ipython which even
supported python 3 at all, as far as I can tell. Because we have a
requirement to use at least python 3 (and not just 3.0 at that), we can
assume that the user must be using at least version 0.11 of ipython.
That means we can remove code which supported older versions.
Change-Id: I7f88aae9f64f6c6f027be52741cda0686f5ca5be
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/50709
Reviewed-by: Andreas Sandberg <andreas.sandberg@arm.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>
There was some code at the end of main.py which would let you run it
directly. This would parse options passed to the script, and show you
what they equaled.
Also, the "main" function would optionally let you pass in options to
override whatever it would find with parse_arguments. This is no longer
used.
Change-Id: Ib0effa7ac2b4a51b68994372a7c7fcf1c9b4dc13
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/50707
Reviewed-by: Jason Lowe-Power <power.jg@gmail.com>
Maintainer: Jason Lowe-Power <power.jg@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Use the VecElem register file when using the 32 bit ARM ABI. This is not
only consistent with an upcoming change which will make the 64 bit
vector registers and the 32 bit vector elements no longer act as views
into the same data, it also simplifies the implementation a little.
Change-Id: Ie8f17b764402a6331012f13b7605520512c2d5c9
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/50207
Reviewed-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
Maintainer: Giacomo Travaglini <giacomo.travaglini@arm.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Pass it in through the constructor, rather than have the MemPool call
into the System object every time it needs the page shift. This is
simpler, more efficient, and removes a dependency between the MemPool
class and the System class.
Change-Id: I059bcb0db249251b32bff1beba3eadfe306d9081
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/50339
Reviewed-by: Matthew Poremba <matthew.poremba@amd.com>
Maintainer: Gabe Black <gabe.black@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Don't look for the m5opRange in the memory pools when allocating memory
so that it can be skipped, just exclude it from the memory pools
entirely when they are set up. This removes a dependence between the
memory pools and the system class.
Change-Id: I0d88c1bc2f889f32b234073cff8988319fb36ea5
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/50338
Reviewed-by: Matthew Poremba <matthew.poremba@amd.com>
Maintainer: Gabe Black <gabe.black@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Expand exclude to work with an AddrRange or AddrRangeList, define
versions to exclude both from an AddrRangeList, and make all available
through subtraction operators. Add -= operators for AddrRangeList with
another AddrRangeList or AddrRange.
Change-Id: Ic48f0c45a4809dbc51e1d3133e8319134aabe29e
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/50347
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Daniel Carvalho <odanrc@yahoo.com.br>
Maintainer: Daniel Carvalho <odanrc@yahoo.com.br>
We go through the trouble of defining an AddrRangeList typedef, but then
we don't use it consistently and use std::vector<AddrRange> instead.
This change converts the exclude method from using
std::vector<AddrRange> to AddrRangeList, and also adds a constructor
which takes an AddrRangeList.
Because there is a lot of code which uses the std::vector based
constructor, this change does not remove that method.
Change-Id: I1a03b25990025688aa760a67d3e7a2e8141384ce
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/50344
Reviewed-by: Daniel Carvalho <odanrc@yahoo.com.br>
Maintainer: Daniel Carvalho <odanrc@yahoo.com.br>
Tested-by: kokoro <noreply+kokoro@google.com>
This complements the --redirect-stdout and --redirect-stderr options and
supresses the message about where those streams are being redirected
which print to the original stdout.
Usually this is very helpful since it lets you know where to look for
simulator output. If you're running gem5 in an automated environment
like our testing framework however, the file name is a random temp file
which will be deleted as soon as the test is finished running.
The --silent-redirect option can be used in these particular scenarios
to, for example, avoid lots and lots of useless lines in the test output
naming files that no longer exist.
Change-Id: If56b61567b3d98abd9cc9d9e9d661ea561be46f8
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/50588
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 'components_library' name was always a placeholder. A more accurate
name would be the 'gem5 library'. This is analogous to standard
libraries shipped as part of programming languages. Over time this will
begin to incorporate more commonly used code at the Python configuration
script level. Most of the former 'components_library' is now in
'gem5.components'.
Change-Id: I5927db7004c43b29c39e7767da3f779627081618
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/49691
Reviewed-by: Bobby R. Bruce <bbruce@ucdavis.edu>
Maintainer: Bobby R. Bruce <bbruce@ucdavis.edu>
Tested-by: kokoro <noreply+kokoro@google.com>
