This simplifies the O3 CPU, and removes special cases around how vector
registers are handled. Now ARM is responsible for maintaining its
different register personalities internally.
Also, this re-establishes the invariant that registers are indexed as
complete, opaque entities with no internal structure, at least as far as
the CPU is concerned.
To make sure the KVM CPU sees the correct state, we need to sync over
the vector registers if we're in 32 bit mode when moving state to or
from gem5's ThreadContext.
Change-Id: I36416d609310ae0bc50c18809f5d9e19bfbb4d37
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/49147
Reviewed-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
Maintainer: Giacomo Travaglini <giacomo.travaglini@arm.com>
Tested-by: kokoro <noreply+kokoro@google.com>
These are called from the ThreadContext, and should not be counted in
the statistics. The (read|set)*Reg methods, aka readIntReg and not
readArchIntReg, are called from the (read|set)*RegOperand methods in the
DynInst, which is the ExecContext implementation when running on O3.
Change-Id: I9abf90fc7bbe80a742325b6dfd3c0e14392af54c
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/51428
Maintainer: Gabe Black <gabe.black@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
The x86 KVM CPU had been in the cpu/kvm directory, while the arm CPU was
inconsistently in the arch/arm directory.
This change moves the x86 CPU to be in arch/x86, restoring consistency.
This location will make the KVM support more modular, by not having the
x86 CPU implementation right alongside the generic implementation.
Change-Id: Ia13151f843df8f8877bfef5ff620825877d3dffa
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/52085
Reviewed-by: Andreas Sandberg <andreas.sandberg@arm.com>
Maintainer: Gabe Black <gabe.black@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
This virtual method can trivially be shared among different CPUs, making
it unnecessary to cast from a BaseCPU pointer to some more specific CPU
class. The existing similar functions which implement this functionality
are only trivially different, and can be merged into overloads of this
common method.
Noteably this method is not implemented for the MinorCPU which uses the
SimpleThread class, typedef-ed to be MinorThread. If the previous
version of this method had been called on that CPU, it would have
crashed the simulator since a dynamic_cast would have failed. This
doesn't provide an implementation for the MinorCPU, but it also doesn't
make the problem worse, and provides a way to actually implement it some
day.
Change-Id: I23399ea6bbbbabd87e6c8bf7a66d48902745d2cf
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/52084
Reviewed-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
Maintainer: Giacomo Travaglini <giacomo.travaglini@arm.com>
Tested-by: kokoro <noreply+kokoro@google.com>
The LSQSenderState that was attached to Request was not useful.
All the fields were either a duplicate of information in the
LSQRequest or totally unused.
The LSQRequest class now inherits from Packet::SenderState and is
attached to the Packet that are sent to memory. We do not need
anymore the indirection Packet->SenderState->LSQRequest.
This helps making the code clearer as it was sometimes hard to
follow the difference between what the LSQRequest and
LSQSenserState was doing
(ex: number of outstanding requests in the memory).
Change-Id: I5b21e007e6d183c6aa79c27c1787ca56dcbc3fb0
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/50733
Reviewed-by: Bobby R. Bruce <bbruce@ucdavis.edu>
Maintainer: Bobby R. Bruce <bbruce@ucdavis.edu>
Tested-by: kokoro <noreply+kokoro@google.com>
The constructor of the LoadQueue and StoreQueue were adding
an additional entry compared to the given configuration.
The removed comment was saying that this additional entry was
used as a dummy entry.
This is not necessary anymore with the current structure.
It was even leading to incorrect behavior as a loadQueue
could have one more outstanding load than specified
by the configuration.
Valgrind does not spot any illegal access.
Change-Id: I41507d003e4d55e91215e21f57119af7b3e4d465
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/50732
Reviewed-by: Bobby R. Bruce <bbruce@ucdavis.edu>
Maintainer: Bobby R. Bruce <bbruce@ucdavis.edu>
Tested-by: kokoro <noreply+kokoro@google.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>
When the scoreboard checks RAW dependency, it determines whether
the source registers can be forwarded or not to evaluate
relative latency. To do that, fuIndices[index] should be used
as an index for accessing cant_forward_from_fu_indices, not register
index itself. Moreover, since fuIndices[index] is cleared as -1
by clearInstDests(), the first compare should be fuIndices[index] != -1
instead of 1.
Change-Id: Ic62546855a8ad5365064d2ea2e2a0fbc1ccc6f41
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/50287
Reviewed-by: ZHENGRONG WANG <seanyukigeek@gmail.com>
Maintainer: ZHENGRONG WANG <seanyukigeek@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.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>
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>
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>
These methods are all identical now. The O3 versions can all be
consolidated into a single method. For the checker CPU, they can
actually be eliminated entirely, and the result queue's "emplace()"
method can be used to add items using less text than just calling the
original helper method.
Change-Id: Ifaeb3beeea257c8bbf951ee1dd8d2d5fd8bb3964
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/49128
Reviewed-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
Maintainer: Giacomo Travaglini <giacomo.travaglini@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>
