In disassembling compressed instructions, the original Gem5 gives needless
operands, such as register or immediate. This patch fixes the problem.
- Existing formats fixed: CIOp, CJOp, CBOp and Jump.
- New formats added: CIAddi4spnOp (for c.addi4spn only) and CompressedROp (with
templates CBasicDeclare and CBasicExecute)
Change-Id: Ic293836983256a59d3a7aca091c8184b410516a4
Signed-off-by: Ian Jiang <ianjiang.ict@gmail.com>
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/22566
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Jason Lowe-Power <jason@lowepower.com>
Reviewed-by: Alec Roelke <alec.roelke@gmail.com>
Maintainer: Alec Roelke <alec.roelke@gmail.com>
For U-type instructions auipc and lui, the 20-bit immediate is left-shifted
by 12 bits in decoding. While the original Gem5 gives the left-shifted
value directly in disassembly.
This patch fixes the problem by
- Assign the original 20-bit immediate to internal variable "imm".
- Output "imm" directly in disassembly, as how the original Gem5 does.
- Do the left-shift to "imm" later in the function defining of each
instruction, rather than in decoding.
Change-Id: I300e26fd9c79478783c39fcd6ff70ea06db88884
Signed-off-by: Ian Jiang <ianjiang.ict@gmail.com>
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/22564
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Jason Lowe-Power <jason@lowepower.com>
Reviewed-by: Alec Roelke <alec.roelke@gmail.com>
Maintainer: Jason Lowe-Power <jason@lowepower.com>
When serialize and unserialize an variable, the parameters passed to
SERIALIZE_SCALAR() and UNSERIALIZE_SCALAR() must be the same and should be a
general variable name. If not, the expected item would not be found with
UNSERIALIZE_SCALAR() and a fatal error would be introduced.
This patch fix the bug in class Interrupts of RISCV.
Change-Id: I7dd7ab6805651149304959bdf7ee9f3be9d9eaff
Signed-off-by: Ian Jiang <ianjiang.ict@gmail.com>
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/22643
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Alec Roelke <alec.roelke@gmail.com>
Maintainer: Alec Roelke <alec.roelke@gmail.com>
These methods will make reporting errors less verbose and more
consistent, since they'll handle some formating, setting colors,
prefixing with an appropriate "Warning:" or "Error:" tag, and exiting
in the case of an error.
Change-Id: Iddea5bf342a4fc4b26002d8e98292f9dc57fa8cc
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/22885
Reviewed-by: Jason Lowe-Power <jason@lowepower.com>
Maintainer: Jason Lowe-Power <jason@lowepower.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Commands that blindly use PROTOC will try to execute "False" which is
very confusing for someone looking at the console output and error
messages. Instead, create a new environment setting HAVE_PROTOC which
is either true or false depending on if the protoc command exists and
passes muster.
Also, if there's an error running protoc, catch that and use it to
mark protoc as unavailable. The previous behavior was to supress errors
and just return an empty string instead, I assume with the expectation
that that would be an invalid version and fail later checks.
Change-Id: I1251b4e7e0e9894cdd3343e59498cc653b648b26
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/22883
Reviewed-by: Jason Lowe-Power <jason@lowepower.com>
Maintainer: Jason Lowe-Power <jason@lowepower.com>
Tested-by: kokoro <noreply+kokoro@google.com>
These tests assume the "end address" is not included in the range. This
exposed some bugs in addr_range.hh which have been fixed. Where
appropriate code comments in addr_range.hh have been extended to improve
understanding of the class's behavior.
Hard-coded AddrRange values in the project have been updated to take
into account that end address is now exclusive. The python params.py
interface has been updated to conform to this new standard.
Change-Id: Idd1e75d5771d198c4b8142b28de0f3a6e9007a52
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/22427
Maintainer: Bobby R. Bruce <bbruce@ucdavis.edu>
Reviewed-by: Nikos Nikoleris <nikos.nikoleris@arm.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Testing intmath.hh and intmath.cc. Here is the
list of the functions that are tested.
intmath.isPowerOf2, intmath.power, intmath.floorLog2,
intmath.ceilLog2, intmath.divCeil, intmath.roundUp,
intmath.roundDown. Other functions are not tested,
because they are not currently used and are dead code.
Change-Id: I150ac1b5cead93c6698a8c9e9cec80bd87ef181a
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/22081
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Mahyar Samani <msamani@ucdavis.edu>
Reviewed-by: Bobby R. Bruce <bbruce@ucdavis.edu>
Maintainer: Bobby R. Bruce <bbruce@ucdavis.edu>
Maintainer: Jason Lowe-Power <jason@lowepower.com>
The below list of functions were dead code and are now
deleted.
intmath.prevPrime, intmath.isPrime, intmath.leastSigBit,
intmath.floorPow2, intmath.ceilPow2, intmath.isHex,
intmath.isOct, intmath.isDec, intmath.hex2Int. The source
file intmath.cc is now effectively useless and deleted.
Change-Id: I28e4350056b8d03e02fecd5c7f7f9c62bc2df7ce
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/22584
Maintainer: Bobby R. Bruce <bbruce@ucdavis.edu>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Daniel Carvalho <odanrc@yahoo.com.br>
Reviewed-by: Jason Lowe-Power <jason@lowepower.com>
Reviewed-by: Gabe Black <gabeblack@google.com>
These namespaces were used to set up an environment/context where there
was an implicit guest namespace. This is an issue when there may be
multiple guest endiannesses which might be different. In cases where
we don't know what the guest endianness is, we can't rely on it being
an implicit part of our context since that would be ambiguous. In cases
where we do know, for instance in ISA specific code, we can just use
the endianness specific version that's appropriate for that context.
This also (somewhat) removes the assumption that there is a single
endianness that applies for a particular ISA. Practically speaking this
assumption will probably still stand though, since there would likely
be a non-trivial performance penalty to apply a configurable endianness
instead of a fixed one the compiler can optomize/remove.
Change-Id: I2dff338b58726d724f387388efe32d9233885680
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/22374
Reviewed-by: Jason Lowe-Power <jason@lowepower.com>
Reviewed-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
Maintainer: Gabe Black <gabeblack@google.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Members `tc` and `ongoingTranslation` were uninitialized in the constructor for
`QueuedPrefetcher::DeferredPacket`. If `ongoingTranslation` is not initialized to
`false` by default, some translation requests from queued prefetchers are not
properly handled and executions are nondeterministic.
Change-Id: Ia278f9e74847d6b847984d47f6a45643bae57794
Signed-off-by: Isaac Sánchez Barrera <isaac.sanchez@bsc.es>
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/22844
Reviewed-by: Nikos Nikoleris <nikos.nikoleris@arm.com>
Maintainer: Nikos Nikoleris <nikos.nikoleris@arm.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Prior to this patch table walks were always cacheable unless
cacheability was globally disabled by SCTLR.C being 0. Arm allows to
select the memory attributes of table walks via the TCR registers.
For example the TCR.IRGN0 bits:
Inner cacheability attribute for memory associated with translation
table walks using TTBR0_EL1.
IRGN0 Meaning
0b00 Normal memory, Inner Non-cacheable.
0b01 Normal memory, Inner Write-Back Read-Allocate Write-Allocate
Cacheable.
0b10 Normal memory, Inner Write-Through Read-Allocate No
Write-Allocate Cacheable.
0b11 Normal memory, Inner Write-Back Read-Allocate No Write-Allocate
Cacheable.
Note: we check IRGNx bits (Inner Shareable domain) instead of ORGNx
(Outer Shareable domain) since in gem5 we consider everything as
Inner Shareable.
Change-Id: If472c218040029c9d165b056a052f522d48d4a82
Signed-off-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
Reviewed-by: Nikos Nikoleris <nikos.nikoleris@arm.com>
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/22723
Tested-by: kokoro <noreply+kokoro@google.com>
In addition to the test, "#include base/logging.hh" was added to the
"byteswap.hh". It is is required to compile the header.
Added tests ByteswapTest.swap_byte64, ByteswapTest.swap_byte32,
ByteswapTest.swap_byte16, ByteswapTest.swap_byte, ByteswapTest.htog,
and ByteswapTest.gtoh. The file byteswap.hh is mostly templates.
Added test for BigEndianGuest and LittleEndianGuest namespaces.
Change-Id: I8870a55594ed439fe9e1fb333384f73261d1b1b8
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/22080
Reviewed-by: Bobby R. Bruce <bbruce@ucdavis.edu>
Maintainer: Bobby R. Bruce <bbruce@ucdavis.edu>
Tested-by: kokoro <noreply+kokoro@google.com>
The new testlib library is looking for regressions walking from
a root folder. This by default points to the tests dir.
Since all regressions are supposed to live in the tests/gem5 subdir,
the patch is assigning the gem5 subdir as a root directory.
This will prevent the example garbage to be printed in the ci framework:
Exception thrown while loading
"/tmpfs/src/git/jenkins-gem5-prod/tests/long/fs/10.linux-boot/test.py"
Ignoring all tests in this file.
Exception thrown while loading
"/tmpfs/src/git/jenkins-gem5-prod/tests/long/fs/80.solaris-boot/test.py"
Ignoring all tests in this file.
[...]
Change-Id: Ia12c6bbeda4ceac71ccd38156ab1e3bb98b05c89
Signed-off-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
Reviewed-by: Nikos Nikoleris <nikos.nikoleris@arm.com>
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/22726
Reviewed-by: Jason Lowe-Power <jason@lowepower.com>
Maintainer: Jason Lowe-Power <jason@lowepower.com>
Tested-by: kokoro <noreply+kokoro@google.com>
The function intmath.leastSigBit is ambiguous given
its name. It does not return the value of the least
significant bit, or the position of the least significant
set bit, but instead 2 to the power of the position of
the least significant set bit. It has thereby been removed
and the function intmath.isPowerOf2 has been refactored to
not require intmath.leastSigBit.
Change-Id: I22479c666cdd059865b8c73b70b5388f98a4584d
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/22583
Reviewed-by: Bobby R. Bruce <bbruce@ucdavis.edu>
Reviewed-by: Daniel Carvalho <odanrc@yahoo.com.br>
Maintainer: Bobby R. Bruce <bbruce@ucdavis.edu>
Tested-by: kokoro <noreply+kokoro@google.com>
The TarmacParser was assuming 32 bit accesses only.
This was creating a mismatch when parsing a trace with 64 bit
accesses.
E.g.
In
clk IT (18) 002001f4 f8008441 O EL3h_s : STR x1,[x2],#8
clk MW8 00201008:000000201008 00000000_40000401
Only the 32 MSBs were checked (00000000)
Change-Id: I51e803b53efe953edcd9378f6c9481c04932331e
Signed-off-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
Reviewed-by: Andreas Sandberg <andreas.sandberg@arm.com>
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/21562
Reviewed-by: Ciro Santilli <ciro.santilli@arm.com>
Tested-by: kokoro <noreply+kokoro@google.com>
An earlier change accidentally left out the actualTC-> prefix in the
getCurrentInstCount method which was supposed to delegate the call to
another thread context. Without that, it just called itself and would
infinitely recurse.
This bug was pointed out in email by Robert Henry.
Change-Id: Ibf1fee6b48ff87790309c6d435bd76fa95c6cab9
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/22623
Reviewed-by: Jason Lowe-Power <jason@lowepower.com>
Maintainer: Jason Lowe-Power <jason@lowepower.com>
Tested-by: kokoro <noreply+kokoro@google.com>
