In this context, the decoder width is the number of bytes that are fed
into the decoder at once. This is frequently the same as the size of an
instruction, but in instructions with occasionally variable instruction
sizes (ARM, RISCV), or extremely variable instruction sizes (x86) there
may be no relation.
Rather than determining the amount of data to feed to the decoder based
on a MachInst type defined by each ISA, this new interface adds some new
properties to the base InstDecoder class each arch specific decoder
inherits from. These are the size of the incoming buffer, a pointer to
wherever that data should end up, and a mask for masking a PC value so
it aligns with the instruction size.
These values are filled in by a templated InstDecoder constructor which
is templated based on what would have historically been the MachInst
type.
Because the "moreBytes" method would historically accept a parameter of
type MachInst, this parameter has also been eliminated. Now, the
decoder's parent object should use the pointer and size values to fill
in the buffer moreBytes reads. Then when moreBytes is called, it just
uses the buffer without having to show what its type is externally.
Change-Id: I0642cdb6a61e152441ca4ce47d748639175cda90
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/40175
Reviewed-by: Gabe Black <gabe.black@gmail.com>
Maintainer: Gabe Black <gabe.black@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
The first non-critical piece of this CL removes the unused self
from the Python function signature.
Then also includes "stl.h" from pybind11 to allow the
implicit conversion from std::map<std::string, std::string>
to a Python dict (otherwise there will be a runtime (not compile time)
error when calling the function.
As the current implementation always throws an error because of the
missing stl.h I don't believe anyone is using this function, and as such
it should be safe to just change the signature of
scx_get_parameter_list.
Change-Id: Ib3202b2d4d1b8418a4adf54739fe389d4ee07743
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/45622
Reviewed-by: Gabe Black <gabe.black@gmail.com>
Maintainer: Gabe Black <gabe.black@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Re-upload of https://gem5-review.googlesource.com/c/public/gem5/+/41214
This provides a layer of indirection where the rounding mode
setting/getting code will do nothing if fenv.h isn't available. At build
time, if fenv.h can't be found, a warning is printed.
Also, the include for fenv.h was guarded in the includes in the ISA
header, but the functions from it weren't guarded in the actual code.
Finally, the code was setting the rounding mode, but not setting it
back. That would mean running these instructions would set the rounding
mode in gem5 as a whole, affecting its other behaviors and any other
instructions that might expect the default rounding mode.
Change-Id: I3ff2b97189487579554aae890e14889bd63461d2
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/44085
Reviewed-by: Gabe Black <gabe.black@gmail.com>
Maintainer: Gabe Black <gabe.black@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
The code in the body of a DPRINTF will always be compiled, even if it's
disabled. If TRACING_ON is false, the if around it will short circuit to
false without actually running any code to check the specified
condition, and the body of the if will be elided by the compiler as
unreachable code.
This creates a more consistent environment whether TRACING_ON is on or
not, so that variables which are only used in DPRINTF don't have to be
guarded by their own TRACING_ON #ifs at the call site. It also ensures
that the code inside DPRINTF is always checked to be valid code, even if
the DPRINTF itself will never go off. This helps avoid syntax errors,
etc, which aren't found because of the configuration of the build being
tested with.
Change-Id: Ia95ae229ebcd2fc9828f62e87f037f76b9279819
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/44988
Maintainer: Gabe Black <gabe.black@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Daniel Carvalho <odanrc@yahoo.com.br>
This is aligning with RISCV and X86. Prior to this patch the Arm
TableWalker was using the TLBVerbose flag. We now use the generic
PageTableWalker flag, in most of the table walker code.
We still rely on the TLBVerbose for some methods.
Those are not conceptually related to the table walker:
For example the memAttrs methods are populating the TLB entry fields
before inserting it in the TLB. Describing the entry fields is
not strictly related to the walking mechanism
Change-Id: Ia75fef052cd44905cc41247f8e590e3ce3912252
Signed-off-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/44966
Reviewed-by: Andreas Sandberg <andreas.sandberg@arm.com>
Maintainer: Andreas Sandberg <andreas.sandberg@arm.com>
Tested-by: kokoro <noreply+kokoro@google.com>
There is a design which has been put forward which eliminates the idea
of a zero register entirely, but in the mean time, to get rid of one
more ISA specific constant, this change moves the ZeroReg constant into
the RegClassInfo class, specifically the IntRegClass instance which is
published by each ISA.
When the idea of zero registers has been eliminated entirely from
non ISA specific code, this and the existing machinery can be
eliminated.
Change-Id: I4302a53220dd5ff6b9b47ecc765bddc6698310ca
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/42685
Reviewed-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
Maintainer: Giacomo Travaglini <giacomo.travaglini@arm.com>
Tested-by: kokoro <noreply+kokoro@google.com>
These instructions go through a lot of effort to extract bitfields, sign
extend them, and cast things to an appropriate type/size.
Instead, we can define a BitUnion which has the appropriate ranges of
bits predefined, and take advantage of the fact that every bitfield
returns its value as either a uint64_t if it's unsigned, or an int64_t
if it's signed.
Also, stop setting resTemp if it's not going to be used to set condition
codes or used as an intermediate in calculating the destination
registers.
Change-Id: Ia511aa74c823fad48080de4fbf77791c0cb3309d
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/42387
Reviewed-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
Maintainer: Giacomo Travaglini <giacomo.travaglini@arm.com>
Tested-by: kokoro <noreply+kokoro@google.com>
The nullStaticInstPtr was low overhead, but the nopStaticInstPtr needed
an actual StaticInst implementation it could point to, and that brought
with it some (minor) additional dependencies. Specifically, the
implementation of advancePC needs the definition of TheISA::PCState,
while all other signatures/impementations in StaticInst are already
passing around that type by reference or could be made to, reducing
dependencies further.
Change-Id: I9ac6a6e5a3106858ea1fc727648f61dc39738a59
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/42968
Reviewed-by: Gabe Black <gabe.black@gmail.com>
Maintainer: Gabe Black <gabe.black@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
While a TLB hit caused by a prefetching operation is visible in terms
of TLB stats update, this is not the case for a TLB miss, which is
invisible to the stats as it is now.
This patch is realigning the behaviour to be more consistent: we will
always update the stats regardless of whether the access caused a
TLB hit/miss
Change-Id: I161e04fc09a0dbba7468a52848aa7710d1476e19
Signed-off-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/37955
Reviewed-by: Tiago Mück <tiago.muck@arm.com>
Reviewed-by: Richard Cooper <richard.cooper@arm.com>
Tested-by: kokoro <noreply+kokoro@google.com>
There are currently only two types of values exported from registers.hh,
vector register definitions, and the zero reg index. The ZeroReg
constant is still defined in registers.hh. The vector register
information has been moved into a new file called arch/arm/regs/vec.hh
since it's used internally by the ISA itself, and then included in
registers.hh so it can be consumed externally too.
Change-Id: I31d8dd5bcb21818efa32ccc42f26b0e598a2c88e
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/41738
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
Maintainer: Giacomo Travaglini <giacomo.travaglini@arm.com>
Maintainer: Bobby R. Bruce <bbruce@ucdavis.edu>
These were not caught by the previous patches because
the grep used ignored:
- anonymous structures
(e.g., "struct {")
- opening braces without leading spaces
(e.g., "struct Name{"),
- weird chars in auto-generation files
(e.g., "struct $name {").
- extra characters after the opening brace.
(e.g., "struct Name { // Comment")
- typedefs (note that this is not caught by the verifier)
(e.g., "typedef struct Name {")
Most of this has been fixed be grepping structures
with the following regex:
grep -nrE --exclude-dir=systemc \
"^ *(typedef)* *(struct|class|enum|union) [^{]*{$" src/
The following makes sure that "struct{" is captured:
grep -nrE --exclude-dir=systemc \
"^ *(struct|class|enum|union){" src/
To find cases that contain a comment after the
opening brace:
grep -nrE --exclude-dir=systemc \
"^ *(struct|class|enum|union)[^{]*{\s*//" src/
Change-Id: I9f822bed628d13b1a09ccd6059373aff63a8d7bd
Signed-off-by: Daniel R. Carvalho <odanrc@yahoo.com.br>
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/43505
Reviewed-by: Bobby R. Bruce <bbruce@ucdavis.edu>
Maintainer: Bobby R. Bruce <bbruce@ucdavis.edu>
Tested-by: kokoro <noreply+kokoro@google.com>
