Create an AllFlagsFlag class which inherits from the CompoundFlag class.
This class is a singleton, and the SimpleFlags install themselves in it
instead of having SCons collect them.
The allFlagsVersion global variable was supposed to be for debugging
according to a comment, but was actually an important part of the "All"
flags inner workings. It was not exposed in the header, but was
redefined/pulled through in src/python/pybind11/debug.cc. The
AllFlagsFlag class now tracks that value, and it can be accessed without
reaching behind the curtain.
This also somewhat decentralizes the debug flag building process in
SCons. The debug/flags.cc still includes all flags at once which
centralizes them, but at least now the "All" flag won't also.
Change-Id: I8430e0fe9022846aade028fb46c80777169a2007
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/48370
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Daniel Carvalho <odanrc@yahoo.com.br>
Reviewed-by: Nathanael Premillieu <nathanael.premillieu@huawei.com>
Reviewed-by: Andreas Sandberg <andreas.sandberg@arm.com>
Maintainer: Andreas Sandberg <andreas.sandberg@arm.com>
X86 had a private/arch specific request flag called StoreCheck which it
used to signal to the TLB that it should fault on a load if it would
have faulted had it been a store. That way, you can detect whether a
read-modify-write type of operation is going to fail due to a
translation problem during the read, and don't have to worry about not
doing anything architecturally visible until the store had succeeded,
while also making sure not to do the store part if the modify part
could fail.
It seems that Ruby had hijacked that flag and had an architecture
specific check which was looking for a load which was going to be
followed by a store. The x86 flag was never intended to communicate that
beyond the TLB, and this nominally architecture agnostic component
shouldn't be reaching into the ISA specific flags to try to get that
information.
Instead, this change introduces a new Request flag called
READ_MODIFY_WRITE which is used for the same purpose in x86, but in
general means that a load will be followed by a write in the near
future.
With this new globally applicable flag, the ruby Sequencer class no
longer needs to check what the arch is, nor does it need to access ISA
private data in the request flags. Always doing this check should be no
less efficient than before, because checking the arch involved calling
into the system object, while checking the flag only requires masking a
bit on the flags which the compiler probably already has floating around
for other logic in this function.
Change-Id: Ied5b744d31e7aa8bf25e399b6b321f9d2020a92f
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/48710
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Bobby R. Bruce <bbruce@ucdavis.edu>
Maintainer: Gabe Black <gabe.black@gmail.com>
In the SConscript, there is a special importer which enables importing
embedded code using various m5.* paths. This was implemented using an
API which has been deprecated and replaced in more recent versions of
python.
Change-Id: I5900f269af48befbcedcb9d25353f04f6297ce9d
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/48363
Tested-by: kokoro <noreply+kokoro@google.com>
Maintainer: Gabe Black <gabe.black@gmail.com>
Reviewed-by: Bobby R. Bruce <bbruce@ucdavis.edu>
This avoids having to explicitly list the types that the result can
hold, avoiding having to specify what the vector types are. Also, the
variant type always has enough space for the result no matter what type
it is. For the "any" type, implementations are encouraged to not
dynamically allocate storage for small values (and RegVal == uint64_t
probably qualifies). This means that for the common case, RegVal, the
amount of storage will be smaller, and only when we actually need space
to store a VecRegContainer, etc, will that actually be allocated.
Change-Id: I43bf8d1866b1538db7d91cd9f1e635df642dd2c9
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/49130
Maintainer: Gabe Black <gabe.black@gmail.com>
Reviewed-by: Yu-hsin Wang <yuhsingw@google.com>
Tested-by: kokoro <noreply+kokoro@google.com>
In a few places, the makeSP helper function was being called on a fixed
register index, INTREG_SPX. That method would always return INTREG_SPX,
so this call was pointless.
Similarly, there were calls to makeZero on the fixed index INTREG_X31
which would return INTREG_ZERO.
It's not clear what the intention of this code was, so this change
simply removes the pointless calls, and makes it clearer what value is
actually being used by the instructions.
Change-Id: I604f013430f180566e1cc44939b145bc5f45f637
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/49763
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
Maintainer: Giacomo Travaglini <giacomo.travaglini@arm.com>
To bridge amba_pv::signal_master_port<bool> with IntPins, we made a
helper class for the purpose. The SignalSender class can be exported as
a gem5 Port, receive the signal, and transfer to fastmodel.
Here's an example showing how it works
*.lisa
```
component
{
slave port<Signal> reset;
}
```
evs.hh
```
class
{
SignalSender reset;
}
```
evs.cc
```
constructor(Params &p) : reset(p.name + ".reset", 0)
{
reset.signal_out.bind(Base::reset);
}
getPort
{
return reset;
}
```
Change-Id: I0936f9ebb2cd60e975661ae78e590285da697771
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/48943
Reviewed-by: Gabe Black <gabe.black@gmail.com>
Maintainer: Gabe Black <gabe.black@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Suppress any valgrind error from *anywhere* in the libpython library.
There are ***many*** false positives in the python library, making the
output of valgrind almost useless without lots of suppressions. Rather
than suppress each error piecemeal, we can suppress any error which
originates in libpython to cover them all.
There will now be corner cases where a bug in gem5 causes some sort of
illegal access, etc, within the python library itself, but these sorts
of interactions/errors should be very rare. Suppressing the fountain of
false positives coming from libpython makes valgrind useable in general,
which IMO is a very worthwhile tradeoff.
Change-Id: I4869eeeb4aef5884ad52025b52c9616e0541f3e6
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/49530
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 register index was for an integer register which was just something
to return when the result should be thrown away. That's basically what
the zero register is/could already be used for. Replace INTREG_DUMMY
with INTREG_ZERO.
Also, change the type used for an index in SVE memory instructions from
IntRegIndex to RegIndex, since it's not actually storing an integer
register index, and g++ gets upset when you try to compare one against a
value which is out of range for that enum.
Change-Id: Ibdc488a2b55162a5f9e3d355126f6c48a99272a9
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/49223
Reviewed-by: Andreas Sandberg <andreas.sandberg@arm.com>
Reviewed-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
Maintainer: Giacomo Travaglini <giacomo.travaglini@arm.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Don't cache the first version requested of object files to use for
subsequent requests. This was originally put in place to avoid an error
when object files could be built with trivially different command lines,
ie command lines which are technically different but not in a
necessarily meaningful way, or less seriously a warning when the command
lines were the same.
The warning was disabled in an earlier change, and the error was avoided
by using a different object file suffix when building unit tests.
This helps avoid bugs if the object files actually *would* turn out to
be different in a meaningful way based on the flags used, and simplifies
the build.
Change-Id: I6b90e6e36b13adb73e587bb8fc533984f764d95a
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/48138
Reviewed-by: Jason Lowe-Power <power.jg@gmail.com>
Maintainer: Gabe Black <gabe.black@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
The systemc headers are supposed to be hermetic, so that they can be
included from generic systemc code without any dependency on the gem5
code base, at least when the systemc components are compiled, outside
of those header files themselves. It should be possible to copy the
"ext" directory out of the tree and make it available to systemc code,
and that code should be compileable.
Change-Id: Iec16a534ac04c7895cd8a30940b0acf64c257dde
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/49618
Maintainer: Bobby R. Bruce <bbruce@ucdavis.edu>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Gabe Black <gabe.black@gmail.com>
blobToCpp is called in two places, one which uses all its functionality,
and one which disables most of it. Instead, factor out the small core so
that it can be called directly by the call sight which uses only that
part, and blobToCpp itself.
This change also removes the ability to leave out a namespace or header
file code formatter, since the function is not called that way any more.
That simplifies blobToCpp significantly.
Change-Id: I63139311521bb4f9287fe41ff51e4e5301a18349
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/48135
Reviewed-by: Gabe Black <gabe.black@gmail.com>
Maintainer: Gabe Black <gabe.black@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Previously, the RISC-V devices queried the system object in
SimObject::init() for the number of CPUs and the number of threads.
However, the system object doesn't actually count the number of
CPUs/threads until it runs init(). Therefore, we've just been getting
lucky in the order that the SimObject init() functions were called.
This change instead decouples these two functions and makes the number
of CPUs/threads a parameter for the RISC-V interrupt devices. This
change also updates the example config script.
Change-Id: Ic4da5604156837cfeec05e58d188b42a02420de1
Signed-off-by: Jason Lowe-Power <jason@lowepower.com>
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/49431
Maintainer: Bobby R. Bruce <bbruce@ucdavis.edu>
Reviewed-by: Ayaz Akram <yazakram@ucdavis.edu>
Tested-by: kokoro <noreply+kokoro@google.com>
This change updates the API in the component library for setting the
size of memory. Now, you can set the size of the memory system as an
argument to the memory object. Then, the board is responsible for
figuring out what the overall memory ranges should be which it
communicates back to the memory system.
This should make multi-channel memories easier to implement and it fixes
some confusion around things like the HiFive platform starting at
0x8000000.
Change-Id: Ibef5aafbbb1177a992950cdc2bd2634dcfb81eec
Signed-off-by: Jason Lowe-Power <jason@lowepower.com>
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/49348
Maintainer: Bobby R. Bruce <bbruce@ucdavis.edu>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Bobby R. Bruce <bbruce@ucdavis.edu>
The runtime coherence check should check the cache heirarchy, not the
global protocol so it can differentiate between Ruby and classic.
This patch also removes some unnecessary includes and fails earlier in
MESI_Two_Level if that protocol isn't built.
Change-Id: I31c1fbd1d9597163b9138e80619d05c132a91545
Signed-off-by: Jason Lowe-Power <jason@lowepower.com>
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/49345
Reviewed-by: Bobby R. Bruce <bbruce@ucdavis.edu>
Maintainer: Bobby R. Bruce <bbruce@ucdavis.edu>
Tested-by: kokoro <noreply+kokoro@google.com>
