The latest Power ISA introduces two new bits that record
carry and overflow out of bit 31 of the result, namely
CA32 and OV32 respectively, thereby changing the behaviour
of the add and subtract instructions that set them. Also,
now that 64-bit registers are being used, the nature of
the result, i.e. less than, greater than or equal to zero,
must be set by a 64-bit signed comparison of the result
to zero. This fixes the following instructions.
* Add Immediate (addi)
* Add Immediate Shifted (addis)
* Add (add[o][.])
* Subtract From (subf[o][.])
* Add Immediate Carrying (addic)
* Add Immediate Carrying and Record (addic.)
* Subtract From Immediate Carrying (subfic)
* Add Carrying (addc[o][.])
* Subtract From Carrying (subfc[o][.])
* Add Extended (adde[o][.])
* Subtract From Extended (subfe[o][.])
* Add to Zero Extended (addze[o][.])
* Subtract From Zero Extended (subfze[o][.])
* Negate (neg[o][.])
* Multiply Low Immediate (mulli)
* Multiply Low Word (mullw[o][.])
* Multiply High Word (mulhw[.])
* Multiply High Word Unsigned (mulhwu[.])
* Divide Word (divw[o][.])
* Divide Word Unsigned (divwu[o][.])
Change-Id: I8c79f1dca8b19010ed7b734d7ec9bb598df428c3
Signed-off-by: Sandipan Das <sandipan@linux.ibm.com>
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/40899
Reviewed-by: Boris Shingarov <shingarov@labware.com>
Maintainer: Jason Lowe-Power <power.jg@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
This changes the base classes for integer arithmetic
instructions and introduces two new classes that are used
to distinguish between instructions using register and
immediate operands.
Decoding has also been consolidated using formats that can
generate code after determining if an instruction records
carry and overflow and also if it records the nature of the
result, i.e. lesser than, greater than or equal to zero.
However, for multiply and divide instructions, the code to
determine if an overflow has occurred has been moved to the
instruction definition itself. The formats have also been
updated to make use of the new base classes.
Change-Id: I23d70ac4bad4d25d876308db0b3564c092bf574c
Signed-off-by: Sandipan Das <sandipan@linux.ibm.com>
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/40898
Reviewed-by: Boris Shingarov <shingarov@labware.com>
Maintainer: Jason Lowe-Power <power.jg@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
This introduces new formats for DS form instructions and
adds the following instructions.
* Load Doubleword (ld)
* Load Doubleword Indexed (ldx)
* Load Doubleword with Update (ldu)
* Load Doubleword with Update Indexed (ldux)
* Store Doubleword (std)
* Store Doubleword Indexed (stdx)
* Store Doubleword with Update (stdu)
* Store Doubleword with Update Indexed (stdux)
Change-Id: I2a88364e82a11685e081f57be5fd5afd44335668
Signed-off-by: Sandipan Das <sandipan@linux.ibm.com>
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/40895
Reviewed-by: Boris Shingarov <shingarov@labware.com>
Reviewed-by: lkcl <luke.leighton@gmail.com>
Maintainer: Jason Lowe-Power <power.jg@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Now that 64-bit registers and operands are being used, the
instructions for words must read or write just one word at
a time. This fixes the following instructions.
* Load Word and Zero (lwz)
* Load Word and Zero Indexed (lwzx)
* Load Word and Zero with Update (lwzu)
* Load Word and Zero with Update Indexed (lwzux)
* Load Word And Reserve Indexed (lwarx)
* Store Word (stw)
* Store Word Indexed (stwx)
* Store Word with Update (stwu)
* Store Word with Update Indexed (stwux)
* Store Word Conditional Indexed (stwcx.)
This also fixes decoding of load-store update instructions
for some special scenarios when RA is zero or RA and RT
are the same. In such cases, the instruction is considered
invalid.
Change-Id: I6787d3614ba8f1b1cbf30a49f85ef422324d7c21
Signed-off-by: Sandipan Das <sandipan@linux.ibm.com>
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/40893
Reviewed-by: Boris Shingarov <shingarov@labware.com>
Maintainer: Jason Lowe-Power <power.jg@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Update in a pmp addr register can have effect on other
pmp rules, for example if TOR mode is used.
According to specs, update in a pmp entry is made using
an update to a pmpaddr reg, followed by an update to pmpcfg
reg which should be followed by sfence.vma. Currently,
in gem5 update in cfg register (combination of 8 pmpcfg
regs.), which should happen after a pmpaddr reg. update,
leads to an update in all pmp rules. However, there seems to
be a case where we receive an interrupt right before execution
of an instruction to update cfg register, which leads to unindented
side-effects of S mode addresses falsely falling into a wrong
pmp region. Updating pmp rules right after pmpaddr update, might
be redundant, but should not break anything otherwise.
Change-Id: I3776ee6ba40e1249c98d11076a2d176de40a957e
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/47059
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 class was adding some complexity on the python/C++ front:
The Stage2MMU was a child of the ArmTLB and parent of the Stage2TLB
However, it's C++ implementation was solely issuing stage2 table walks
and was not handling the stage2 translation logic in general.
We are removing the class and moving its implemetation structures
within the table walker.
This simplifies the code: the nested Stage2Translation class has
been renamed to Stage2Walk to make its purpose more explicit
The MMU has now a centralized view of all TLBs and Table Walkers in the
system
Change-Id: I8a13a5b793abb7e602e9a05a908e7e0ec3c37247
Signed-off-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/45780
Reviewed-by: Andreas Sandberg <andreas.sandberg@arm.com>
Maintainer: Andreas Sandberg <andreas.sandberg@arm.com>
Tested-by: kokoro <noreply+kokoro@google.com>
According to privileged ISA specs, a valid 64 bit virtual address should
have bit 63-39 same as bit 38 (for Sv39). Without this change, kernel page
fault handler does not seem to work correctly. For example, while running
a program, the kernel was segfaulting complaining that it cannot handle
kernel paging request at some virtual address (which is the faulting
address returned by gem5 currently, with all bits after first 39 cleared).
With this change, that error goes away.
Change-Id: Iae7c9d0af19e29214e14a0db08d7c0ac122122bc
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/45920
Reviewed-by: Jason Lowe-Power <power.jg@gmail.com>
Reviewed-by: Nils Asmussen <nils.asmussen@barkhauseninstitut.org>
Maintainer: Jason Lowe-Power <power.jg@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
As part of recent decisions regarding namespace
naming conventions, all namespaces will be changed
to snake case.
::Stats became ::statistics.
"statistics" was chosen over "stats" to avoid generating
conflicts with the already existing variables (there are
way too many "stats" in the codebase), which would make
this patch even more disturbing for the users.
Change-Id: If877b12d7dac356f86e3b3d941bf7558a4fd8719
Signed-off-by: Daniel R. Carvalho <odanrc@yahoo.com.br>
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/45421
Reviewed-by: Jason Lowe-Power <power.jg@gmail.com>
Maintainer: Jason Lowe-Power <power.jg@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
As part of recent decisions regarding namespace
naming conventions, all namespaces will be changed
to snake case.
::ProbePoints became ::probing.
"probing" was chosen over "probe_points" because the
namespace contains more than solely probe points; it
contains all classes related to the act of probing.
Change-Id: I44567974a521707593739a2bd5933391803e5b51
Signed-off-by: Daniel R. Carvalho <odanrc@yahoo.com.br>
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/45412
Maintainer: Jason Lowe-Power <power.jg@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Hoa Nguyen <hoanguyen@ucdavis.edu>
The only thing brought in by arch/types.hh is TheISA::PCState. Instead
of having the other types around where they could be used accidentally,
and to make it more obvious what's being exported, this change splits
PCState out into a new switching header called arch/pcstate.hh. The
original arch/types.hh is no longer a switching header, and includes
pcstate.hh.
Change-Id: I8dfd298349e4565f316f7b9a028703289ada6010
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/40177
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Gabe Black <gabe.black@gmail.com>
Maintainer: Gabe Black <gabe.black@gmail.com>
If RS1 is X0 or if using an immediate and the value encoded in the RS1
field which is used as the immediate is zero, then the CSR is not
actually written. It doesn't matter whether the register value would
change or not.
Also, if an instruction wants to write to the CSR, the manual does not
say anything about whether or not the register value changes. If a
register is read only, attempting to write it with *any* value should be
illegal.
Change-Id: Ic876eff0fc0c7e25a40ba9213e3c3e49bfa7a33e
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/45522
Reviewed-by: Ayaz Akram <yazakram@ucdavis.edu>
Maintainer: Gabe Black <gabe.black@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
These had been templated on a type, and then the width of that type was
considered the amount the PC should advance when executing straight line
code. That type was MachInst, which was loosely the size of an
instruction, but was practically whatever sized data type was fed into
the decoder at a time.
Instead of tying this to a type, this change moves it over to be a
simple number. This avoids a level of indirection, and also further
decouples the type the decoder might use as input from the instruction
size.
Change-Id: I797876a33d27e759c7a6e23a658179201fabfa47
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/40176
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Gabe Black <gabe.black@gmail.com>
Maintainer: Bobby R. Bruce <bbruce@ucdavis.edu>
By moving the installation of even the first ThreadContext out of the
constructor, it's possible to construct the stub separately. We can then
move the code that creates the stub out of the base class and into
architecture specific sub-classes.
Change-Id: I0dfd53a3135ebc98ec49acf81d83e58830bc365c
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/44618
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Gabe Black <gabe.black@gmail.com>
Maintainer: Gabe Black <gabe.black@gmail.com>
When using remote GDB to debug an x86 simulated system within gem5, the
stub within gem5 needs to decide what arch the GDB instance expects.
That determines what format the blob of data with register values should
be.
Previously, gem5 would make that decision based on the current mode of
the target thread context. If the target was currently executing in 64
bit mode, that would imply that GDB was expecting 64 bit registers. If
not, then it was probably trying to debug a 32 bit program and would
expect 32 bit registers.
That works in many circumstances, but won't work if, for instance, a CPU
has not yet been initialized and is not running in its final, typical
mode, or if it's dipped into another mode to, for instance, run a user
mode program which is 32 bit under a 64 bit kernel.
This change modifies the GDB stub to first try to use the workload
object to determine what arch the GDB instance is most likely to assume.
This is a reasonably accurate representation for the arch GDB expects,
even though there isn't a direct, enforced link. It would be best if GDB
could just tell us what it expected, but I wasn't able to find any way
to get it to do that.
In most (all?) cases where someone would be using GDB to debug the guest
there will be a workload, and that workload will have a well defined
architecture. Since that isn't technically required though, this change
will still fall back to the old detection mechanism if it can't tell
from the workload, or if there is no workload in the first place.
Later revisions of the GDB interface may tie the remote GDB stub to the
workload object itself, in which case it *will* be possible to assume
that a workload object exists, and the workload object will be able to
explicitly select what GDB stub to use based on what it's running. In
the mean time, this seems like a fairly robust approximation of that.
Change-Id: I5059d48c28380e2fee5629d832acf95063a1a27a
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/44614
Reviewed-by: Daniel Carvalho <odanrc@yahoo.com.br>
Maintainer: Gabe Black <gabe.black@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Figure out more about what the CSR instructions are supposed to do at
decode/instruction construction time, instead of at run time. An
instruction will usually be constructed many fewer times than it will be
executed, so we can perform the work once and then use it many times.
Change-Id: I9941bb2555e67a6c738aa3dfdca1b4857427b71c
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/45521
Reviewed-by: Ayaz Akram <yazakram@ucdavis.edu>
Maintainer: Gabe Black <gabe.black@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
As part of recent decisions regarding namespace
naming conventions, all namespaces will be changed
to snake case.
sim_clock::Int became sim_clock::as_int.
"as_int" was chosen because "int" is a reserved
keyword, and this namespace acts as a selector of
how to read the internal variables.
Another possibility to resolve this would be to
remove the namespaces "Float" and "Int" and use
unions instead.
Change-Id: I65f47608d2212424bed1731c7f53d242d5a7d89a
Signed-off-by: Daniel R. Carvalho <odanrc@yahoo.com.br>
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/45436
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Hoa Nguyen <hoanguyen@ucdavis.edu>
Maintainer: Gabe Black <gabe.black@gmail.com>
As part of recent decisions regarding namespace
naming conventions, all namespaces will be changed
to snake case.
sim_clock::Float became sim_clock::as_float.
"as_float" was chosen because "float" is a reserved
keywords, and this namespace acts as a selector of
how to read the internal variables. Another
possibility to resolve this would be to remove the
namespaces "Float" and "Int" and use unions instead.
Change-Id: I7b3d9c6e9ab547493d5596c7eda080a25509a730
Signed-off-by: Daniel R. Carvalho <odanrc@yahoo.com.br>
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/45435
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Hoa Nguyen <hoanguyen@ucdavis.edu>
Maintainer: Gabe Black <gabe.black@gmail.com>
As part of recent decisions regarding namespace
naming conventions, all namespaces will be changed
to snake case.
X86Macroop became x86_macroop.
Ideally, this should probably be moved to inside the
X86ISA namespace, and renamed accordingly, but a macroop
namespace would probably generate a lot of conflicts.
Change-Id: I06bc0f33a4c1d95492df9397d7d70e5316b1b96b
Signed-off-by: Daniel R. Carvalho <odanrc@yahoo.com.br>
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/45400
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Gabe Black <gabe.black@gmail.com>
Maintainer: Gabe Black <gabe.black@gmail.com>
