These were not caught by the previous patches because
the grep used ignored:
- anonymous structures
(e.g., "struct {")
- opening braces without leading spaces
(e.g., "struct Name{"),
- weird chars in auto-generation files
(e.g., "struct $name {").
- extra characters after the opening brace.
(e.g., "struct Name { // Comment")
- typedefs (note that this is not caught by the verifier)
(e.g., "typedef struct Name {")
Most of this has been fixed be grepping structures
with the following regex:
grep -nrE --exclude-dir=systemc \
"^ *(typedef)* *(struct|class|enum|union) [^{]*{$" src/
The following makes sure that "struct{" is captured:
grep -nrE --exclude-dir=systemc \
"^ *(struct|class|enum|union){" src/
To find cases that contain a comment after the
opening brace:
grep -nrE --exclude-dir=systemc \
"^ *(struct|class|enum|union)[^{]*{\s*//" src/
Change-Id: I9f822bed628d13b1a09ccd6059373aff63a8d7bd
Signed-off-by: Daniel R. Carvalho <odanrc@yahoo.com.br>
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/43505
Reviewed-by: Bobby R. Bruce <bbruce@ucdavis.edu>
Maintainer: Bobby R. Bruce <bbruce@ucdavis.edu>
Tested-by: kokoro <noreply+kokoro@google.com>
The systemc dir was not included in this fix.
First it was identified that there were only occurrences
at 0, 1, and 2 levels of indentation (and 2 of 2 spaces,
1 of 3 spaces and 2 of 12 spaces), using:
grep -nrE --exclude-dir=systemc \
"^ *enum [A-Za-z].* {$" src/
Then the following commands were run to replace:
<indent level>enum X ... {
by:
<indent level>enum X ...
<indent level>{
Level 0:
grep -nrl --exclude-dir=systemc \
"^enum [A-Za-z].* {$" src/ | \
xargs sed -Ei \
's/^enum ([A-Za-z].*) \{$/enum \1\n\{/g'
Level 1:
grep -nrl --exclude-dir=systemc \
"^ enum [A-Za-z].* {$" src/ | \
xargs sed -Ei \
's/^ enum ([A-Za-z].*) \{$/ enum \1\n \{/g'
and so on.
Change-Id: Ib186cf379049098ceaec20dfe4d1edcedd5f940d
Signed-off-by: Daniel R. Carvalho <odanrc@yahoo.com.br>
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/43326
Reviewed-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
Reviewed-by: Gabe Black <gabe.black@gmail.com>
Maintainer: Giacomo Travaglini <giacomo.travaglini@arm.com>
Tested-by: kokoro <noreply+kokoro@google.com>
This should help reduce warning spew when building with newer compilers.
The pybind11::module type has been renamed pybind11::module_ to avoid
conflicts with c++20 modules, according to the pybind11 changelog, so
this CL also updates gem5 source to use the new type. There is
supposedly an alias pybind11::module which is for compatibility, but we
still get linker errors without changing to pybind11::module_.
Change-Id: I0acb36215b33e3a713866baec43f5af630c356ee
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/40255
Maintainer: Bobby R. Bruce <bbruce@ucdavis.edu>
Reviewed-by: Bobby R. Bruce <bbruce@ucdavis.edu>
Tested-by: kokoro <noreply+kokoro@google.com>
We currently use the traditional SI-like prefixes to represent
binary multipliers in some contexts. This is ambiguous in many cases
since they overload the meaning of the SI prefix.
Here are some examples of commonly used in the industry:
* Storage vendors define 1 MB as 10**6 bytes
* Memory vendors define 1 MB as 2**20 bytes
* Network equipment treats 1Mbit/s as 10**6 bits/s
* Memory vendors define 1Mbit as 2**20 bits
In practice, this means that a FLASH chip on a storage bus uses
decimal prefixes, but that same flash chip on a memory bus uses binary
prefixes. It would also be reasonable to assume that the contents of a
1Mbit FLASH chip would take 0.1s to transfer over a 10Mbit Ethernet
link. That's however not the case due to different meanings of the
prefix.
The quantity 2MX is treated differently by gem5 depending on the unit
X:
* Physical quantities (s, Hz, V, A, J, K, C, F) use decimal prefixes.
* Interconnect and NoC bandwidths (B/s) use binary prefixes.
* Network bandwidths (bps) use decimal prefixes.
* Memory sizes and storage sizes (B) use binary prefixes.
Mitigate this ambiguity by consistently using the ISO/IEC/SI prefixes
for binary multipliers for parameters and comments where appropriate.
Change-Id: I3d0bbfa00968486af8d57c36be2c8bee034bae93
Signed-off-by: Andreas Sandberg <andreas.sandberg@arm.com>
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/39577
Reviewed-by: Daniel Carvalho <odanrc@yahoo.com.br>
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 are times when we need to change the name of parameter, but this
breaks the external-facing python API used in configuration files. Using
this "type" for a parameter will warn users that they are using the old
name, but allow for backwards compatibility.
Declaring a SimObject parameter of type `DeprecatedParam` allows the
python configuration files to use the old name transparently. This
leverages some of the SimObject magic to remember the names of
deprecated parameters and the DeprecatedParam object stores the
"translation" from old name to new name.
This has been tested with Ports, "normal" parameters, and SimObject
parameters. It has not been tested with checkpointing as there are no
checkpointing tests in gem5 right now. The testing was manually adding
some deprecated params and checking that config scripts still run
correctly that use the old, deprecated, variables.
Change-Id: I0465a748c08a24278d6b1a9d9ee1bcd67baa5b13
Signed-off-by: Jason Lowe-Power <jason@lowepower.com>
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/31954
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 decorator creates two versions of a class, adding it to the Params
dict multiple times which generates an annoying warning. Alternatively,
the with_metaclass mechanism sets up an alternative base class which
does not create the extra class and doesn't generate the warning.
It may be the case that this generates extra classes which just don't
lead to a warning? Or in other words, would we then have Params types
with weird, internal names generated by six? Hopefully not, but that may
be preferable to the annoying warnings, especially when running tests
which run gem5 many times.
Change-Id: I9395cde3fc95126c0a0c4db67fc5b0c6bf2dd9ed
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/33276
Reviewed-by: Andreas Sandberg <andreas.sandberg@arm.com>
Maintainer: Andreas Sandberg <andreas.sandberg@arm.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Python 2.x and Python 3 use different meta class syntax. Fix this by
implementing meta classes using the add_metaclass decorator in the six
Python library.
Due to the way meta classes are implemented in six,
MetaParamValue.__new__ seems to be called twice for some classes. This
triggers an assertion which when param that checks that Param types
have only been registered once. I have turned this assertion into a
warning.
The assertion was triggered in params.CheckedInt and params.Enum. It
seems like the cause of the issue is that these classes have their own
meta classes (CheckedIntType and MetaEnum) that inherit from
MetaParamValue and a base class (ParamValue) that also inherits from
MetaParamValue.
Change-Id: I5dea08bf0558cfca57897a124cb131c78114e59e
Signed-off-by: Andreas Sandberg <andreas.sandberg@arm.com>
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/26083
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Jason Lowe-Power <jason@lowepower.com>
Maintainer: Jason Lowe-Power <jason@lowepower.com>
These tests assume the "end address" is not included in the range. This
exposed some bugs in addr_range.hh which have been fixed. Where
appropriate code comments in addr_range.hh have been extended to improve
understanding of the class's behavior.
Hard-coded AddrRange values in the project have been updated to take
into account that end address is now exclusive. The python params.py
interface has been updated to conform to this new standard.
Change-Id: Idd1e75d5771d198c4b8142b28de0f3a6e9007a52
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/22427
Maintainer: Bobby R. Bruce <bbruce@ucdavis.edu>
Reviewed-by: Nikos Nikoleris <nikos.nikoleris@arm.com>
Tested-by: kokoro <noreply+kokoro@google.com>
A recent change got rid of the strict Master => Slave port relationship
which used to be checked in python and instead left the checking up to
C++. One major downside to this approach is that it was no longer
obvious in the configuration what was supposed to be connected to what,
and it still left the arbitrary and misleading MasterPort and SlavePort
types in the Ethernet devices which could now connect with each other
symmetrically but couldn't actually connect to an arbitrary
MasterPort/SlavePort.
This change exposes the base Port and VectorPort types, and makes them
accept a "role" parameter in __init__ which used to be set directly by
their subclasses. This role can be any string, and will be used later
to check for compatiblity and to give a hint as to what can be
connected to what in the SimObject definitions.
To make the checks work with arbitrary compatible pairs, the base Port
type now has a class method called compat() which accepts a pair of
roles which will become mutually compatible, ie any port with the first
role will be allowed to connect to any port with the second role, and
vice versa. To be self compatible, the same role should be passed in
for both parameters.
To maintain compatibility, the MasterPort and SlavePort types are
retained, but now they're nothing special and could have been set up
in any arbitrary SimObject .py file. The same is true for
MasterVectorPort and SlaveVectorPort.
Also, since we can no longer assume that all edges in the dot graph of
the config should start with a port with the MASTER role and end with
a port with the SLAVE role, Ports now track an is_source property which
says whether the arrow head should be surpressed at that end of the
edge representing the connection.
Change-Id: Ifcc6faab05e437ad87cd21f0ba613b09cf21c321
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/18168
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Andreas Sandberg <andreas.sandberg@arm.com>
Maintainer: Gabe Black <gabeblack@google.com>
This retrieves ports using the getPort method, and connects them using
the bind method on the ports themselves. Any smarts as far as what type
of peers are allowed to connect or how they connect is left up to the
individual bind methods.
Change-Id: Ic640d1fce8af1bed411116e5830edc4a8a0f9d66
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/17039
Reviewed-by: Andreas Sandberg <andreas.sandberg@arm.com>
Maintainer: Andreas Sandberg <andreas.sandberg@arm.com>
There is a circular dependency between params and proxy at import
time. This causes issues for Python 3. Add the imports to the specific
methods with the dependencies to make the import happen when the
method is executed instead.
Change-Id: I770112fd3c07c395459e204976942bda3dc7236f
Signed-off-by: Andreas Sandberg <andreas.sandberg@arm.com>
Reviewed-on: https://gem5-review.googlesource.com/c/15993
Reviewed-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
Reviewed-by: Juha Jäykkä <juha.jaykka@arm.com>
Many functions that used to return lists (e.g., dict.items()) now
return iterators and their iterator counterparts (e.g.,
dict.iteritems()) have been removed. Switch calls to the Python 2.7
iterator methods to use the Python 3 equivalent and add explicit list
conversions where necessary.
Change-Id: I0c18114955af8f4932d81fb689a0adb939dafaba
Signed-off-by: Andreas Sandberg <andreas.sandberg@arm.com>
Reviewed-on: https://gem5-review.googlesource.com/c/15992
Reviewed-by: Juha Jäykkä <juha.jaykka@arm.com>
Reviewed-by: Jason Lowe-Power <jason@lowepower.com>
Add missing operators to NumericParamValue and ensure that they are
able to work on the underlying value if the right hand side is a
param.
Change-Id: I2bd86662aee9891bbd89aed7ebe20b827b5528bd
Signed-off-by: Andreas Sandberg <andreas.sandberg@arm.com>
Reviewed-on: https://gem5-review.googlesource.com/c/16001
Reviewed-by: Nikos Nikoleris <nikos.nikoleris@arm.com>
When initializing a param with a SimObject NULL pointer, convert()
checks if the 'ptype' attribute has been created and whether the value
is NULL. In that case, it assumes that the object is being
initizalized as a part of SimObject initialization and defers the
conversion. This check is implemented using hasattr() which in turn is
implemented using the __getattr__ implementation that asserts because
all SimObjects haven't been initialized yet.
Implement the check using a lookup in the object's dictionary instead
to prevent the SimObject lookup.
Change-Id: I7367563c4fb71f6d2be541ebdc0be418e9f73d48
Signed-off-by: Andreas Sandberg <andreas.sandberg@arm.com>
Reviewed-on: https://gem5-review.googlesource.com/c/15990
Reviewed-by: Nikos Nikoleris <nikos.nikoleris@arm.com>
params.py checks the validity of memory port-port connections before
they are instantiated in C++. This commit ensures that attempting to
connect two slave ports together will cause a TypeError.
Change-Id: Ia7d0a15df28b96c7bf5e568c4f4917d21a19b824
Reviewed-by: Nikos Nikoleris <nikos.nikoleris@arm.com>
Reviewed-on: https://gem5-review.googlesource.com/c/15896
Reviewed-by: Andreas Sandberg <andreas.sandberg@arm.com>
Maintainer: Andreas Sandberg <andreas.sandberg@arm.com>
At the moment gem5 has support for enum params that either generate a
unscoped within the Enums namespace or a struct encapsulated enum. The
Enums namespace is getting quite big and some params have the same
names which results in collisions. This change adds support for the
scoped enums.
Change-Id: I930e1cc3b814081627b653939e75d6c43956a334
Signed-off-by: Nikos Nikoleris <nikos.nikoleris@arm.com>
Reviewed-by: Andreas Sandberg <andreas.sandberg@arm.com>
Reviewed-on: https://gem5-review.googlesource.com/c/15395
Reviewed-by: Jason Lowe-Power <jason@lowepower.com>
Maintainer: Jason Lowe-Power <jason@lowepower.com>
The error checking in that function used an if/else structure where
one of the two branches would be the error condition which would cause
the function to exit. Because the function would exit if an error was
detected, there's no reason to have the non-error condition guarded in
the other half of the if.
This change de-nests the non-error cases to make the function simpler
and easier to read.
Change-Id: Idedf54e84a178fa5a2a47f96373374152e420cf3
Reviewed-on: https://gem5-review.googlesource.com/c/15516
Reviewed-by: Andreas Sandberg <andreas.sandberg@arm.com>
Maintainer: Andreas Sandberg <andreas.sandberg@arm.com>
Starting with version 3, scons imposes using the print function instead
of the print statement in code it processes. To get things building
again, this change moves all python code within gem5 to use the
function version. Another change by another author separately made this
same change to the site_tools and site_init.py files.
Change-Id: I2de7dc3b1be756baad6f60574c47c8b7e80ea3b0
Reviewed-on: https://gem5-review.googlesource.com/8761
Reviewed-by: Andreas Sandberg <andreas.sandberg@arm.com>
Reviewed-by: Jason Lowe-Power <jason@lowepower.com>
Maintainer: Gabe Black <gabeblack@google.com>
These had a lot of code which duplicated what was already in the
Float param value class. Also, printing into the ini file with "%f"
forces python to truncate values which require more precision than the
fixed float format supports.
Change-Id: Iad9623b71a31d17b69c184082585dcbb881eaa20
Reviewed-on: https://gem5-review.googlesource.com/5622
Reviewed-by: Andreas Sandberg <andreas.sandberg@arm.com>
Maintainer: Andreas Sandberg <andreas.sandberg@arm.com>
The existing code was essentially doing the same thing, but in a more
roundabout and obscure way. One difference between the two versions is that
I believe this will stop as soon as it encounters an element without a
parent, where the original version would call has_parent() on all the
elements regardless.
Change-Id: Ia1fef3083fc88fca11f8ecfca453476e33194695
Reviewed-on: https://gem5-review.googlesource.com/4842
Reviewed-by: Jason Lowe-Power <jason@lowepower.com>
Maintainer: Gabe Black <gabeblack@google.com>
NullSimObject doesn't have a has_parent function, and it's not clear what its
return value should be if one were added. The appropriate value seems to
depend on why some other bit of code is checking if there's a parent in the
first place.
In SimObjectVector, the has_parent function is checking whether all of its
elements have a parent. In this particular case, the most reasonable thing
to do seems to be to just skip those elements.
Change-Id: I5f8cad66d1b22c5e37962492fd77cff9371e5af8
Reviewed-on: https://gem5-review.googlesource.com/4841
Reviewed-by: Jason Lowe-Power <jason@lowepower.com>
Maintainer: Gabe Black <gabeblack@google.com>
This lets attempts to set_parent on NullSimObject fall away harmlessly
without having to add a bunch of checks whenever set_parent is called.
Change-Id: I6d3510772ba71e765c4739e486e9f3d2460c4e11
Reviewed-on: https://gem5-review.googlesource.com/4840
Reviewed-by: Jason Lowe-Power <jason@lowepower.com>
Maintainer: Gabe Black <gabeblack@google.com>
Previously proxy vector parameters would resolve correctly only for
Parent.all. Any other proxy such as Parent.any, or exact ones such as
Parent.addr_range would resolve to a *vector* of the right value
resulting into a vector of a vector. For example if we set:
DirectoryController0.addr_range = [0x100000-0x1fffff, 0x200000-0x2fffff]
DirectoryMemory0.addr_range = Parent.addr_range
where DirectoryController0 is the parent SimObject of DirectoryMemory0
after unproxying the Parent.addr_range VectorParam we would get
DirectoryMemory0.addr_range = [[0x100000-0x1fffff, 0x200000-0x2fffff]]
This change unifies handling of all three proxies to the same correct
unproxy mechanism.
Change-Id: Ie5107f69f58eb700b3e1b92c55210e0d53e6788d
Reviewed-by: Andreas Sandberg <andreas.sandberg@arm.com>
Reviewed-on: https://gem5-review.googlesource.com/2901
Maintainer: Andreas Sandberg <andreas.sandberg@arm.com>
Reviewed-by: Jason Lowe-Power <jason@lowepower.com>
Use the PyBind11 wrapping infrastructure instead of SWIG to generate
wrappers for functionality that needs to be exported to Python. This
has several benefits:
* PyBind11 can be redistributed with gem5, which means that we have
full control of the version used. This avoid a large number of
hard-to-debug SWIG issues we have seen in the past.
* PyBind11 doesn't rely on a custom C++ parser, instead it relies on
wrappers being explicitly declared in C++. The leads to slightly
more boiler-plate code in manually created wrappers, but doesn't
doesn't increase the overall code size. A big benefit is that this
avoids strange compilation errors when SWIG doesn't understand
modern language features.
* Unlike SWIG, there is no risk that the wrapper code incorporates
incorrect type casts (this has happened on numerous occasions in
the past) since these will result in compile-time errors.
As a part of this change, the mechanism to define exported methods has
been redesigned slightly. New methods can be exported either by
declaring them in the SimObject declaration and decorating them with
the cxxMethod decorator or by adding an instance of
PyBindMethod/PyBindProperty to the cxx_exports class variable. The
decorator has the added benefit of making it possible to add a
docstring and naming the method's parameters.
The new wrappers have the following known issues:
* Global events can't be memory managed correctly. This was the
case in SWIG as well.
Change-Id: I88c5a95b6cf6c32fa9e1ad31dfc08b2e8199a763
Signed-off-by: Andreas Sandberg <andreas.sandberg@arm.com>
Reviewed-by: Andreas Hansson <andreas.hansson@arm.com>
Reviewed-by: Andrew Bardsley <andrew.bardsley@arm.com>
Reviewed-on: https://gem5-review.googlesource.com/2231
Reviewed-by: Tony Gutierrez <anthony.gutierrez@amd.com>
Reviewed-by: Pierre-Yves Péneau <pierre-yves.peneau@lirmm.fr>
Reviewed-by: Jason Lowe-Power <jason@lowepower.com>
