We were simply not declaring the source files for PySource files if
built --without-python. Instead, we should declare them, but then
explicitly exclude them if that option is set.
Since we're already doing that, we can simply remove the check from the
PySource constructor.
Change-Id: I437ebeee1082fa00065bedd61f91d5721b915ae5
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/49389
Maintainer: Gabe Black <gabe.black@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Hoa Nguyen <hoanguyen@ucdavis.edu>
The compileDate and gem5Version fields are used in only one place,
gem5's python main function. These fields are the remaining difference
between the "fake" defines.py provided by the SimObject importer, and
the real one composed later. It makes sense to exclude them in the
"fake" version since those values come from c++, but it would feel like
an arbitrary and unexpected difference to people trying to use it.
Change-Id: Ie344765bf7c8063197da24f5b55f762379deff94
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/48380
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Jason Lowe-Power <power.jg@gmail.com>
Maintainer: Jason Lowe-Power <power.jg@gmail.com>
Commit c417b76 changed the behaviour of addRequest(),
but did not update documentation or the HTM-related logic that used it.
Updates documentation for addRequest() in light of c417b76,
refactors request class to be idiomatic and use assigned byteEnable,
made HTM cmds pass in a correct byteEnable.
Change-Id: I7aa8c127df896e81caf915fbfea93e7b4bcc53b7
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/50147
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 had been done by prepending the letter "t" to the suffix, with the
intention of turning a suffix like ".o" to ".to". Unfortunately SCons
stores both the actual suffix and the "." in that variable, so what we
ended up with was ".o" => "t.o", so test.o would become testt.o.
This change updates that logic to prepend a ".t" in front of the
existing suffix, skipping over it's first character which is assumed to
be a ".".
Change-Id: Id8c5f893413284868c2dc2a1a5e879b86790ed76
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/50067
Reviewed-by: Bobby R. Bruce <bbruce@ucdavis.edu>
Maintainer: Bobby R. Bruce <bbruce@ucdavis.edu>
Tested-by: kokoro <noreply+kokoro@google.com>
Use templates to delegate knowing what these types are to whatever is using
InstResult. This will need to be even more generalized at these call
sights so that we don't just push around the dependencies, but that will
have to be handled later.
Change-Id: I45915d70ea06caed06f0ccf356f9e2e1acbd6c61
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/49131
Reviewed-by: Yu-hsin Wang <yuhsingw@google.com>
Maintainer: Gabe Black <gabe.black@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
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>
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>
