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>
Rather than decode and call each PsuedoInst function one by one, we can
use a GuestABI which knows how to marshal arguments and return values
and call the pseudoInst dispatch function which will do the work for us,
and make SPARC able to call any pseudo inst, not just the ones it was
hard coded to recognize.
Change-Id: I28192c4feeaf86a77c0f23c5b131929e45ec6d74
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/42388
Maintainer: Bobby R. Bruce <bbruce@ucdavis.edu>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Gabe Black <gabe.black@gmail.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>
Several sext<> calls had an off by one sign bit index, which is really
the size of the number which is being sign extended. Also, two calls in
arch/sparc/tlb.cc seemed to assume that the argument to that function
was modified in place, where really the new value is returned
separately. Move the call to sext so its return value is used and not
thrown away.
Change-Id: I86cb81ad243558e1a0d33def7f3eebe6973d6800
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/42603
Reviewed-by: Daniel Carvalho <odanrc@yahoo.com.br>
Reviewed-by: Bobby R. Bruce <bbruce@ucdavis.edu>
Reviewed-by: Boris Shingarov <shingarov@gmail.com>
Maintainer: Bobby R. Bruce <bbruce@ucdavis.edu>
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>
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>
The only thing left in isa_traits.hh are two constants, one for the
number of bytes in a page, and one for how far to shift an address to
get the page number. To make it clear that this is the only thing
isa_traits.hh should be used for from this point forward (until it is
entirely eliminated), this change renames it to the much less generic
page_size.hh.
Also, because isa_traits.hh used to have *much* more stuff in it, it was
included in a lot of places it didn't need to be. This change also
clears out all these legacy includes while updating the actually needed
ones to the new name.
Change-Id: I939b01b117c53d620b6b0a98982f6f21dc2ada72
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/40179
Reviewed-by: Gabe Black <gabe.black@gmail.com>
Maintainer: Gabe Black <gabe.black@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Most ISAs used that constant exactly once, when setting up a Process.
This change just propogates the constant to the one place it's used. In
MIPS, the endianness is hard coded as little. There were some checks
which would change the behavior if the endianness was big. This change
removes that dead code. If someone wants to add support for big endian
MIPS, they can go back and add in the small bits of code that would be
required. It's likely the existing big endian support was incomplete and
not tested, so it's probably best for someone interested in it to start
fresh anyway.
Change-Id: Ife6ffcf4bca40001d5d9126f7d795f954f66bb22
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/40178
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
Reviewed-by: Daniel Carvalho <odanrc@yahoo.com.br>
Maintainer: Giacomo Travaglini <giacomo.travaglini@arm.com>
The systemc dir was not included in this fix.
First it was identified that there were only occurrences
at 0, 1, and 2 levels of indentation (and 2 of 2 spaces,
1 of 3 spaces and 2 of 12 spaces), using:
grep -nrE --exclude-dir=systemc \
"^ *enum [A-Za-z].* {$" src/
Then the following commands were run to replace:
<indent level>enum X ... {
by:
<indent level>enum X ...
<indent level>{
Level 0:
grep -nrl --exclude-dir=systemc \
"^enum [A-Za-z].* {$" src/ | \
xargs sed -Ei \
's/^enum ([A-Za-z].*) \{$/enum \1\n\{/g'
Level 1:
grep -nrl --exclude-dir=systemc \
"^ enum [A-Za-z].* {$" src/ | \
xargs sed -Ei \
's/^ enum ([A-Za-z].*) \{$/ enum \1\n \{/g'
and so on.
Change-Id: Ib186cf379049098ceaec20dfe4d1edcedd5f940d
Signed-off-by: Daniel R. Carvalho <odanrc@yahoo.com.br>
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/43326
Reviewed-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
Reviewed-by: Gabe Black <gabe.black@gmail.com>
Maintainer: Giacomo Travaglini <giacomo.travaglini@arm.com>
Tested-by: kokoro <noreply+kokoro@google.com>
In most ISAs except MIPS and Power, this was implemented as
inst->advancePC(). It works just fine to call this function all the
time, but the idea had originally been that for ISAs which could simply
advance the PC using the PC itself, they could save the virtual function
call. Since the only ISAs which could skip the call were MIPS and Power,
and neither is at the point where that level of performance tuning
matters, this function can be collapsed with little downside.
If this turns out to be a performance bottleneck in the future, the way
the PC is managed could be revisited to see if we can factor out this
trip to the instruction object in the first place.
Change-Id: I533d1ad316e5c936466c529b7f1238a9ab87bd1c
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/39335
Maintainer: Gabe Black <gabe.black@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
Reviewed-by: Alex Dutu <alexandru.dutu@amd.com>
This was an inline function defined for each ISA, but really it makes
more sense for it to be defined by the instruction classes. The actual
return address for any given instruction can best be calculated when you
know what that instruction actually does, and also the instructions will
know about ISA level PC management.
Change-Id: I2c5203aefa90f2f26ecd94e82b925c6b552e33d3
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/39324
Reviewed-by: Gabe Black <gabe.black@gmail.com>
Maintainer: Gabe Black <gabe.black@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
The patch is using the newly defined PARAMS macro to replace
custom params() getters in derived class.
The patch is also removing redundant _params:
Instead of creating yet another _params field, SimObject descendants
should use params() to expose the real type of SimObject::_params they
already have.
Change-Id: I43394cebb9661fe747bdbb332236f0f0181b3dba
Signed-off-by: Alexander Klimov <Alexander.Klimov@arm.com>
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/39900
Reviewed-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
Maintainer: Giacomo Travaglini <giacomo.travaglini@arm.com>
Tested-by: kokoro <noreply+kokoro@google.com>
The idea of this template was to distinguish types which should
grow/shrink based on the native size of the ABI in question. Or in other
words, if the ABI was 32 bit, the type should also be 32 bit, or 64 bit
and 64 bit.
Unfortunately, I had intended for Addr to be a conforming type (since
local pointers would be conforming), but uint64_t not to be. Since Addr
is defined as a typedef of uint64_t, the compiler would make *both*
types conforming, giving incorrect behavior on 32 bit systems.
Local pointers will need to be handled in a different way, likely with
the VPtr template, so that they will be treated correctly and not like
an explicitly 64 bit data type.
Change-Id: Idfdd5351260b48bb531a1926b93e0478a297826d
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/40495
Reviewed-by: Gabe Black <gabe.black@gmail.com>
Maintainer: Gabe Black <gabe.black@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
This DPRINTF accesses the ExtMachInst typed machInst member of the
StaticInst class, and so is ISA dependent. Move the DPRINTF to where the
instructions are actually decoded where that type doesn't have to be
disambiguated.
Also, this change makes this DPRINTF more accurate, since microops are
not really "decoded" when they are extracted from a macroop. The process
of unpacking them to feed into the rest of the CPU should be fairly
trivial, so really they're just being retrieved. With the DPRINTF in
this new position, it will only trigger when an instruction is actually
decoded from memory.
Change-Id: I14145165b93bb004057a729fa7909cd2d3d34d29
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/40099
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 base/refcnt.hh header was not used in base/types.hh at all, and
enum/ByteOrder.hh was there just so other files could find it. Instead,
this change moves enum/Byteorder.hh to sim/byteswap.hh where it's fits
with the purpose of the header.
This change also fixes some style problems with the code in
base/types.hh itself.
Change-Id: I471ae5cb2cca9169ba8616fb8411b40108a3ffb2
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/39855
Reviewed-by: Daniel Carvalho <odanrc@yahoo.com.br>
Maintainer: Gabe Black <gabe.black@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Once all ISAs are converted, the base StaticInst class will be able to
drop its local arrays, and will no longer need to know what the global
maximum number of source or destination registers is for a given
instruction.
Most of the convertion was very simple and just involved adding tags to
declare and install the register arrays in all the class definitions.
Since SPARC has a relatively simple ISA definition, there weren't many
places that needed to be updated.
The exception was the BlockMem template, which was declaring the microop
classes within the body of the macroop. That was ok when those
declarations didn't need anything other than the name of their parent,
but now they also need to know how big to declare their arrays based on
their actual implementation.
To facilitate that, and to significantly streamline the definition of
the macroop class, the microop class definitions were moved to their own
template, and only the declaration was left in the parent class.
Change-Id: I09e6b1d1041c6a0aeaee63ce5f9a18cf482b6203
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/36879
Reviewed-by: Gabe Black <gabe.black@gmail.com>
Maintainer: Gabe Black <gabe.black@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
There were accessors for reading these indexes, but they were not
consistently used. This change makes them private to StaticInst, and
changes places that were accessing them directly to instead use the
accessors. New accessors are added for code generated by the ISA parser
and some ARM code to set the indexes without accessing them directly.
By forcing these values to be behind accessors, it will be much simpler
to change how those values are stored and retrieved.
Change-Id: Icca80023d7f89e29504fac6b194881f88aedeec2
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/36875
Reviewed-by: Andreas Sandberg <andreas.sandberg@arm.com>
Maintainer: Andreas Sandberg <andreas.sandberg@arm.com>
Tested-by: kokoro <noreply+kokoro@google.com>
The event in KVM x86 SE mode plays double duty, triggering a system call
or a page fault depending on where it's called from (the system call
handler vs page fault handler).
This means we can eliminate the page fault gem5 op and the
pseudo_inst.hh switching header file.
This change touches a lot of things, but there wasn't really a good
place to split it up which still made sense and was consistent and
functional.
Change-Id: Ic414829917bcbd421893aa6c89d78273e4926b78
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/34165
Reviewed-by: Gabe Black <gabe.black@gmail.com>
Reviewed-by: Alexandru Duțu <alexandru.dutu@amd.com>
Maintainer: Gabe Black <gabe.black@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
In SPARC and SE mode, system calls are triggered by a trap exception
with the appropriate trap number, and then a handler within the Workload
(formerly the Process) object recognizes the trap number and triggers
the system call.
For Linux, this special handling happens in the Linux specific Workload,
and other types of traps are passed through to the base SPARC SE
Workload class. For Solaris however, no special handling is implemented.
That means that it's actually impossible for a Solaris SE mode program
to actually trigger a system call, and so while there is some code
written for Solaris SE mode, this feature does not actually work at all.
Also, while it's relatively easy to build binaries for Linux on various
architectures using, for instance, the crosstool-ng configs in util/,
there is no ready made option that I could find for building a SPARC
Solaris cross compiler which would run on x86 linux.
Given that the support that exists isn't actually hooked up properly,
SPARC is not one of the most popular ISAs within gem5, Solaris is not a
widely used operating system, we have (to my knowledge) no test binary
to run, and setting up a cross compiler would be non-trivial, it makes
the most sense to me to remove this support.
Change-Id: I896b5abc4bf337bd4e4c06c49de7111a3b2b784c
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/33996
Reviewed-by: Gabe Black <gabe.black@gmail.com>
Maintainer: Gabe Black <gabe.black@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>