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>
This function used makeAtomicOpFunctor to create a unique_ptr which
pointed to an AtomicOpFunctor *, which it immediately extracted with
.get(). Then since the temporary unique_ptr went out of scope, it
deleted the AtomicOpFunctor which it just returned a pointer to.
Instead, that function should create a local unique_ptr to pass
ownership of the object off to. It will still be cleaned up when it
goes out of scope, but not before it's done being used.
Change-Id: I74a0bcbb719a78a3e9ec8cb2ea5aa15120da0456
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/49023
Reviewed-by: Matt Sinclair <mattdsinclair@gmail.com>
Reviewed-by: Bobby R. Bruce <bbruce@ucdavis.edu>
Reviewed-by: Kyle Roarty <kyleroarty1716@gmail.com>
Maintainer: Matt Sinclair <mattdsinclair@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
At the moment the ITLBI and DTLBI operations where implicitly
implemented as generic TLBIs
e.g:
* DTLBIASID, ITLBIASID = TLBIASID
This was possible as a single TLB was either an instruction TLB
or a data TLB and no generic/shared TLB option was available.
In other words, an ITLBI Op to an ITB was invalidating all entries
as we were sure the ITB was not containing data entries.
With shared TLBs, this doesn't hold true and we need to explicitly
implement I/DTLBIs
JIRA: https://gem5.atlassian.net/browse/GEM5-790
Change-Id: I39a4add7674f6008dacaedfd1fd90560d264048e
Signed-off-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/48148
Reviewed-by: Andreas Sandberg <andreas.sandberg@arm.com>
Maintainer: Andreas Sandberg <andreas.sandberg@arm.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Now all occurances of the THE_ISA macro which were being used to check
for anything other than the NULL_ISA have been eliminated. We still need
to be able to check whether the current ISA is the null ISA, but we
don't want to let any preprocessor checks back in which are based on
what the current ISA is.
This change removes the THE_ISA macro, and replaces it with IS_NULL_ISA
which evaluates to 1 if the ISA is null, and 0 if it isn't.
Jira Issue: https://gem5.atlassian.net/browse/GEM5-1060
Change-Id: Iec146b40d8cab846dae03e15191390f754f2b71b
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/48709
Reviewed-by: Hoa Nguyen <hoanguyen@ucdavis.edu>
Maintainer: Gabe Black <gabe.black@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
The ISAs we support today mostly have a micropc, whether that's used
very heavily like on x86, or sparsely like on ARM, RISCV or SPARC. Only
MIPS and POWER don't currently use a micropc, and neither of those is
performance tuned to the point where adding some size to the PC object
should make a meaningful difference.
Because most ISAs already have a micropc anyway, and some minimal part
of managing the micropc has to be part of the guaranteed interface so
that the CPUs can work, it's a small step to make the micropc more
completely part of the base class.
This change also makes uReset part of the guaranteed interface so we can
get rid of an #if THE_ISA == in the minor CPU.
Jira Issue: https://gem5.atlassian.net/browse/GEM5-1060
Change-Id: Ide55a8feaee0bd5fff1d7ec05f95ad30a496b196
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/48704
Reviewed-by: Hoa Nguyen <hoanguyen@ucdavis.edu>
Maintainer: Gabe Black <gabe.black@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
It is possible from the MMU to traverse the entire hierarchy of
TLBs, starting from the DTB and ITB (generally speaking from the
first level) up to the last level via the nextLevel pointer. So
in theory no extra data should be stored in the BaseMMU.
This design makes some operations a bit more complex. For example
if we have a unified (I+D) L2, it will be pointed by both ITB and
DTB. If we want to invalidate all TLB entries, we should be
careful to not invalidate L2 twice, but if we simply follow the
next level pointer, we might do so. This is not a problem from
a functional perspective but alters the TLB statistics (a single
invalidation is recorded twice)
We then provide a different view of the set of TLBs in the system.
At the init phase we traverse the TLB hierarchy and we add every
TLB to the appropriate set. This makes invalidation (and any
operation targeting a specific kind of TLBs) easier.
JIRA: https://gem5.atlassian.net/browse/GEM5-790
Change-Id: Ieb833c2328e9daeaf50a32b79b970f77f3e874f7
Signed-off-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/48146
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Jason Lowe-Power <power.jg@gmail.com>
Reviewed-by: Andreas Sandberg <andreas.sandberg@arm.com>
Maintainer: Jason Lowe-Power <power.jg@gmail.com>
Maintainer: Andreas Sandberg <andreas.sandberg@arm.com>
This patch is moving most of the TLB code to the MMU.
In this way the TLB stops being the main translating agent and becomes a
simple "passive" translation cache.
All the logic behind virtual memory translation, like
* Checking permission/alignment
* Issuing page table walks
* etc
Is now embedded in the MMU model. This will allow us to stack multiple
TLBs and to compose arbitrary hierarchies as their sole purpose now is
to cache translations
JIRA: https://gem5.atlassian.net/browse/GEM5-790
Change-Id: I687c639a56263d5e3bb6633dd8c9666c85edba3a
Signed-off-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/48141
Tested-by: kokoro <noreply+kokoro@google.com>
Now that we're using c++17, the type_traits with a ::value member have
a _v alias which reduces verbosity. Or on other words
std::is_integral<T>::value
can be replaced with
std::is_integral_v<T>
Make this substitution throughout the code base. In places where gem5
introduced it's own similar templates, add a V alias, spelled
differently to match gem5's internal style.
gem5: :IsVarArgs<T>::value => gem5::IsVarArgsV<T>
Change-Id: I1d84ffc4a236ad699471569e7916ec17fe5f109a
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/48604
Reviewed-by: Daniel Carvalho <odanrc@yahoo.com.br>
Maintainer: Bobby R. Bruce <bbruce@ucdavis.edu>
Tested-by: kokoro <noreply+kokoro@google.com>
Memory space is not always outside of the CPU. For example the tightly
coupled memory (TCM) is inside of the core. To make gdb access those
kind of memory, we should use Iris memory API to read and write memory.
If we access a memory address not inside the CPU with Iris memory API.
The CPU would fire a request via amba transport_dbg. So the change also
covers the original behavior.
Change-Id: Ie223ab12f9a746ebafa21026a8680222f6ebd593
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/45581
Reviewed-by: Gabe Black <gabe.black@gmail.com>
Maintainer: Gabe Black <gabe.black@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
