This has been in this file since it was created in 2009. No global "using
namespace ${NAMESPACE}" should ever appear in a .hh file since then that
namespace is "used" in all files that include the .hh, even if they
aren't aware of it or even actively don't want to.
Change-Id: Idb7d7c5b959077eb4905fbb2044aa55959b8f37f
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/34155
Reviewed-by: Andreas Sandberg <andreas.sandberg@arm.com>
Maintainer: Andreas Sandberg <andreas.sandberg@arm.com>
Tested-by: kokoro <noreply+kokoro@google.com>
When isa_traits.hh hopefully goes away in the not too distant future,
this constant will need somewhere to live so ARM components can find it.
There are valid arguments that this should not be a constant in the
first place, but that's outside the scope of this change.
Change-Id: Ic5bd046dc1cc196b3cf6b6c36878fdbf5eb4c0bf
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/34170
Reviewed-by: Andreas Sandberg <andreas.sandberg@arm.com>
Maintainer: Andreas Sandberg <andreas.sandberg@arm.com>
Tested-by: kokoro <noreply+kokoro@google.com>
When the system call happens during the execution of the system call
instruction, it can be ambiguous what state takes precedence, the state
update from the instruction or the system call. These may be tracked
differently and found in an unpredictable order in, for example, the O3
CPU. An instruction can avoid updating any state explicitly, but
implicitly updated state (specifically the PC) will always update,
whether the instruction wants it to or not.
If the system call can be deferred by using a Fault object, then it's no
longer ambiguous. The PC update will be discarded, and the system call
can set the PC however it likes. Because there is no implicit PC update,
the PC needs to be walked forward, either to what it would have been
anyway, or to what the system call set in NPC.
In addition, because of the existing semantics around handling Faults,
the instruction no longer needs to be marked as serializing,
non-speculative, etc.
The "normal", aka architectural, aka FS version of the system call
instructions don't return a Fault artificially.
Change-Id: I72011a16a89332b1dcfb01c79f2f0d75c55ab773
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/33281
Maintainer: Gabe Black <gabeblack@google.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Andreas Sandberg <andreas.sandberg@arm.com>
Gem5 Hardware Transactional Memory (HTM)
Here we provide a brief note describing HTM support in Gem5 at
a high level.
HTM is an architectural feature that enables speculative concurrency in
a shared-memory system; groups of instructions known as transactions are
executed as an atomic unit. The system allows that transactions be
executed concurrently but intervenes if a transaction's
atomicity/isolation is jeapordised and takes corrective action. In this
implementation, corrective active explicitely means rolling back a
thread's architectural state and reverting any memory updates to a point
just before the transaction began.
This HTM implementation relies on--
(1) A checkpointing mechanism for architectural register state.
(2) Buffering speculative memory updates.
This patch is focusing on the definition of the HTM checkpoint (1)
The checkpointing mechanism is architecture dependent. Each ISA
leveraging HTM support can define a class HTMCheckpoint inhereting from
the generic one (GenericISA::HTMCheckpoint).
Those will need to save/restore the architectural state by overriding
the virtual HTMCheckpoint::save (when starting a transaction) and
HTMCheckpoint::restore (when aborting a transaction).
Instances of this class live in O3's ThreadState and Atomic's
SimpleThread. It is up to the ISA to populate this instance when
executing an instruction that begins a new transaction.
JIRA: https://gem5.atlassian.net/browse/GEM5-587
Change-Id: Icd8d1913d23652d78fe89e930ab1e302eb52363d
Signed-off-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/30314
Reviewed-by: Jason Lowe-Power <power.jg@gmail.com>
Maintainer: Jason Lowe-Power <power.jg@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
isa_traits.hh used to have much more in it, but now it only has
PageShift, PageBytes, and (for now) the guest endianness. These values
should only be retrieved from the System class generally speaking, so
only the system class should include arch/isa_traits.hh.
Some gpu compute related files need PageBytes or PageShift. Even though
those files don't advertise their ISA dependence, they are tied to x86.
In those files, they can include arch/x86/isa_traits.hh.
The only other file which legitimately needs arch/isa_traits.hh is the
decoder cache since it uses PageBytes to size an array.
Change-Id: I12686368715623e3140a68a7027c136bd52567b1
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/33203
Reviewed-by: Gabe Black <gabeblack@google.com>
Reviewed-by: Daniel Carvalho <odanrc@yahoo.com.br>
Maintainer: Gabe Black <gabeblack@google.com>
Tested-by: kokoro <noreply+kokoro@google.com>
The 'jalr' instruction of 'format Jump' should have an immediate as
offset, and the Rd register could not be always omitted. This patch
fixes the problem.
Example output:
jalr ra, -168(ra)
jalr zero, 0(ra)
jalr ra, 0(a5)
Note that this does not apply to the other two instructions of the
same format: 'c.jr' and 'c.jalr'.
Change-Id: Ia656c2e8bfafd243bfec221ac291190a84684929
Signed-off-by: Ian Jiang <ianjiang.ict@gmail.com>
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/33155
Reviewed-by: Jason Lowe-Power <power.jg@gmail.com>
Maintainer: Jason Lowe-Power <power.jg@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
The VAddr class wasn't used and was just a copy (with style fixes) of
the Alpha version.
Delete unused constants in isa_traits.hh, and remove unnecessary
includes. Replace MachineBytes with sizeof(uint32_t) in
arch/power/process.cc.
Change-Id: Ia4862448c43b2dd07078b1ebbbbfda4636343730
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/33199
Reviewed-by: Jason Lowe-Power <power.jg@gmail.com>
Maintainer: Jason Lowe-Power <power.jg@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
In flat instructions, wrLmReqsInPipe/rdLmReqsInPipe are decremented
in the calcAddr() function. However, the calcAddr() function is only
called when execMask != 0.
This patch adds in statements to decrement wrLmReqsInPipe and
rdLmReqsInPipe in all implemented atomic flats when execMask is 0.
This fixes a scenario where vector local memory and flat instructions
are unable to execute due to LocalMemPipeline::isLMReqFIFOWrRdy
always returning false in ScheduleStage::dispatchReady after too many
atomic flats execute with execMask = 0
Change-Id: I081cfd3faf74bbfcf0728445e7160fa2a76a6a7e
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/32614
Reviewed-by: Matt Sinclair <mattdsinclair@gmail.com>
Reviewed-by: Alexandru Duțu <alexandru.dutu@amd.com>
Maintainer: Anthony Gutierrez <anthony.gutierrez@amd.com>
Tested-by: kokoro <noreply+kokoro@google.com>
In most cases, the microcode ROM doesn't actually do anything. The
structural existence of a microcode ROM doesn't make sense in the
general case, and in architectures that know they have one and need to
interact with it, they can cast their decoder into an arch specific type
and access the ROM that way.
Change-Id: I25b67bfe65df1fdb84eb5bc894cfcb83da1ce64b
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/32898
Reviewed-by: Andreas Sandberg <andreas.sandberg@arm.com>
Maintainer: Andreas Sandberg <andreas.sandberg@arm.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Some variables were being compared against some constants with "is not",
which is not correct since it will compare for identity rather than
equivalence. There was a long standing build warning from this, but it
wasn't clear where the error was coming from since it was in python
interpreted from a string in the ISA description.
This change replaces "is not" in those two places with "!=".
Change-Id: I0c4d038af6e047ffd79f8171713e8e998e840e3b
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/33283
Maintainer: Gabe Black <gabeblack@google.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Bobby R. Bruce <bbruce@ucdavis.edu>
Original Creator: Adria Armejach.
Branch instructions needed to be annotated in x86 as direct/indirect and conditional/unconditional. These annotations where not present causing the branch predictor to misbehave, not using the BTB. In addition, logic to determine the real branch target at decode needed to be added as it was also missing.
Change-Id: I91e707452c1825b9bb4ae75c3f599da489ae5b9a
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/29154
Reviewed-by: Alexandru Duțu <alexandru.dutu@amd.com>
Maintainer: Jason Lowe-Power <power.jg@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
This code was at least a little Alpha specific, and now that Alpha is
gone it can no longer be compiled. We could either fix it up to work
with other/all ISAs or delete it, and the consensus was to delete it. It
could potentially be revived in the future by retrieving it from version
control.
Change-Id: Ied073f2b9b166951ecba3442cd762eb19bc690b3
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/32954
Reviewed-by: Steve Reinhardt <stever@gmail.com>
Maintainer: Gabe Black <gabeblack@google.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Also remove it's Alpha centric implementation. All existing ISAs will
panic since they all define the guarding constant as false. Even if they
defined it as true, this function assumes that there is necessarily a misc
reg which can be read to find the current thread_info struct, and how
the contents of that register should be manipulated.
This code is already fairly fragile since it depends on things in the
Linux kernel having certain names and relationships with each other, but
that's a larger problem I don't want to fix right now.
Change-Id: Ic107793ebcd25ee25c4d3713c84c1d2b5209f1a3
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/32921
Reviewed-by: Andreas Sandberg <andreas.sandberg@arm.com>
Maintainer: Gabe Black <gabeblack@google.com>
Tested-by: kokoro <noreply+kokoro@google.com>
The getDoubleBits function was used exactly once to find the bit
representation of a double floating point value, which is the same thing
the common floatToBits64 function does. Eliminate x86's one off version,
and use the common one instead.
Change-Id: Icb0cec5a55d81a6eacf1bb5a3c2b8f16c414d0d9
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/32927
Reviewed-by: Andreas Sandberg <andreas.sandberg@arm.com>
Maintainer: Gabe Black <gabeblack@google.com>
Tested-by: kokoro <noreply+kokoro@google.com>
