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>
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>
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>
Only use "using namespace" with the *ISAInst namespace, not the top
level namespace. Also only using namespace *ISA, and not the gem5
namespace itself. The *ISAInst namespace is already in the gem5
namespace, and so will resolve names in it automatically.
Change-Id: Iebf3c9519c65baba073d73744665f8c98880804c
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/49887
Reviewed-by: Daniel Carvalho <odanrc@yahoo.com.br>
Maintainer: Gabe Black <gabe.black@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.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 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>
The "predicate"s for reading/writing some condition code registers were
written with constants which were built up from other constants which
represent individual bits in the condition code register. There are
existing constants which already exactly match those sets of bits, so we
can just use those instead of building up the same thing in-situ.
Change-Id: Iab5a5de04d0fd858414451531a357770ca9fde14
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/49244
Reviewed-by: Matt Sinclair <mattdsinclair@gmail.com>
Maintainer: Matt Sinclair <mattdsinclair@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Because MediaOps have two sizes, one for sources and one for
destinations, it does not have a single dataSize member to set the size
of its operands. This was difficult to correct at the time, so a
dataSize member was created which was fixed at 0, and the instructions
themselves would use srcSize and destSize internally to do the actual
computation.
That causes problems when tracing, since the printReg function needs to
know what size to use to print some registers properly, specifically
integer registers.
To now fix that problem, some SFINAE constructors have been added which
will either pass through a dataSize member if one exists, or pass
through a pointer to the instruction itself so that operand index
selector class can pick out the member that makes sense for it (destSize
for DestOp, srcSize for Src1Op and Src2Op).
Change-Id: I6b8259a5ab27f809b81453bcf987cc6d1be4811a
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/49203
Tested-by: kokoro <noreply+kokoro@google.com>
Maintainer: Gabe Black <gabe.black@gmail.com>
Reviewed-by: Matt Sinclair <mattdsinclair@gmail.com>
These *used* to have a source register which was the syscall number.
That was not an actual property of the instruction, it was a property of
the syscall mechanism in Linux which had leaked into the implementation
of the instructions themselves.
That was corrected by removing that source register and letting the
syscall handling layer figure out which system call to invoke.
Unfortunately the SyscallInst format wasn't also updated, and when
printing the disassembly for those instructions, it would try to print
that source register. That instruction doesn't bother to set up a source
operand array since it doesn't actually have any, so that ended up
accessing random memory.
Change-Id: I20890ad69605983305a13f414ca59a5fa35d4d06
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/49183
Reviewed-by: Jason Lowe-Power <power.jg@gmail.com>
Maintainer: Jason Lowe-Power <power.jg@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
