The systemc dir was not included in this fix.
First it was identified that there were only occurrences
at 0, 1, 2 and 3 levels of indentation (and a single
occurrence of 2 and 3 spaces), using:
grep -nrE --exclude-dir=systemc \
"^ *struct [A-Za-z].* {$" src/
Then the following commands were run to replace:
<indent level>struct X ... {
by:
<indent level>struct X ...
<indent level>{
Level 0:
grep -nrl --exclude-dir=systemc
"^struct [A-Za-z].* {$" src/ | \
xargs sed -Ei \
's/^struct ([A-Za-z].*) \{$/struct \1\n\{/g'
Level 1:
grep -nrl --exclude-dir=systemc \
"^ struct [A-Za-z].* {$" src/ | \
xargs sed -Ei \
's/^ struct ([A-Za-z].*) \{$/ struct \1\n \{/g'
and so on.
Change-Id: I362ef58c86912dabdd272c7debb8d25d587cd455
Signed-off-by: Daniel R. Carvalho <odanrc@yahoo.com.br>
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/39017
Reviewed-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
Maintainer: Giacomo Travaglini <giacomo.travaglini@arm.com>
Tested-by: kokoro <noreply+kokoro@google.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, using:
grep -nrE --exclude-dir=systemc \
"^ *class [A-Za-z].* {$" src/
Then the following commands were run to replace:
<indent level>class X ... {
by:
<indent level>class X ...
<indent level>{
Level 0:
grep -nrl --exclude-dir=systemc
"^class [A-Za-z].* {$" src/ | \
xargs sed -Ei \
's/^class ([A-Za-z].*) \{$/class \1\n\{/g'
Level 1:
grep -nrl --exclude-dir=systemc \
"^ class [A-Za-z].* {$" src/ | \
xargs sed -Ei \
's/^ class ([A-Za-z].*) \{$/ class \1\n \{/g'
and so on.
Change-Id: I17615ce16a333d69867b27c7bae0f4fdafd8b2eb
Signed-off-by: Daniel R. Carvalho <odanrc@yahoo.com.br>
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/39015
Reviewed-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
Maintainer: Giacomo Travaglini <giacomo.travaglini@arm.com>
Tested-by: kokoro <noreply+kokoro@google.com>
There is no way to make this sort of template work with more than one
ISA at a time, and it's also more complex than it needs to be,
particularly since the methods within it are never used in performance
critical code. Using virtual functions is also simpler and uses less
code.
Change-Id: I0baa1a651fa656420f6f90776572f8700a6d7cab
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/40106
Reviewed-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
Maintainer: Giacomo Travaglini <giacomo.travaglini@arm.com>
Tested-by: kokoro <noreply+kokoro@google.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>
This function causes problems with gcc 5 which incorrectly complains
about the call to warn_if inside a constexpr function. That should only
be an error if a call to a non-constexpr is unavoidable, and even then
the compiler isn't required to emit a diagnostic.
Rather than drop the warning, or add ifdefs to deal with these defective
versions of gcc, this change eliminates the power() function entirely.
Most inputs to this function would overflow anyway, which is reportedly
why no integer version of an exponentiation function is defined in the
standard library, and all uses of this function can easily and more
efficiently be replaced by simple left and right shifts.
Finally, by eliminating the power() function, we also remove the
dependence on base/logging.hh.
Change-Id: I4d014163883d12db46da4ee752696c8225534ee8
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/42504
Reviewed-by: Gabe Black <gabe.black@gmail.com>
Maintainer: Gabe Black <gabe.black@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Each vectorReg operand defined a set of seven elements which all
followed a very predictable pattern. Since we already have a small
utility function to help generate those definitions, we can just
generate the elements at the same time and save a lot of boilerplate.
Change-Id: I065c6c319612b79c53570b313bf5ad8770796252
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/41896
Reviewed-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
Maintainer: Giacomo Travaglini <giacomo.travaglini@arm.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 mismatches were from places where Params structs had been declared
as classes instead of structs, and ruby's MachineID struct.
A comment describing why the warning had been disabled said that it was
because of libstdc++ version 4.8. As far as I can tell, that version is
old enough to be outside the window we support, and so that should no
longer be a problem. It looks like the oldest version of gcc we
support, 5.0, corresponds with approximately libstdc++ version 6.0.21.
https://gcc.gnu.org/onlinedocs/libstdc++/manual/abi.html#abi.versioning
Change-Id: I75ad92f3723a1883bd47e3919c5572a353344047
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/40953
Reviewed-by: Gabe Black <gabe.black@gmail.com>
Maintainer: Gabe Black <gabe.black@gmail.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 type is primarily used to determine the size of a pointer when
using that ABI, similar to the uintptr_t type, but also less directly
to determine the "native" size of the ABI. For instance, for 32 bit ARM
ABIs, it should be defined as uint32_t since that's both the size of a
uintptr_t, and, less directly, the size of a 32 bit ARM register and
"naturally" sized types in that ABI.
This type can be used by the VPtr template to retrieve its actual value
from a simcall's parameters. In general, when accepting or returning a
pointer or address in a simcall, the VPtr template should be used so
that it's managed correctly by GuestABI. Addr will be treated as a
uint64_t allways which will be incorrect for 32 bit ABIs.
Change-Id: I3af046917387541d6faff96a21a1f1dbf7317e06
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/40496
Maintainer: Gabe Black <gabe.black@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Bobby R. Bruce <bbruce@ucdavis.edu>
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>
This takes the place of direct access to the machInst field as used in
the MinorCPU model which makes the incorrect assumption that it can
arbitrarily treat the ExtMachInst as an integer, and that masking in a
certain way can meaningfully classify what the instruction will do.
Because that assumption is not correct in general, that had been
ifdef-ed out in most ISAs except ARM, and for the other ISAs the value
was simply set to zero.
Change-Id: I8ac05e65475edc3ccc044afdff09490e2c05ba07
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/40098
Reviewed-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
Maintainer: Giacomo Travaglini <giacomo.travaglini@arm.com>
Maintainer: Bobby R. Bruce <bbruce@ucdavis.edu>
Tested-by: kokoro <noreply+kokoro@google.com>
This should help reduce warning spew when building with newer compilers.
The pybind11::module type has been renamed pybind11::module_ to avoid
conflicts with c++20 modules, according to the pybind11 changelog, so
this CL also updates gem5 source to use the new type. There is
supposedly an alias pybind11::module which is for compatibility, but we
still get linker errors without changing to pybind11::module_.
Change-Id: I0acb36215b33e3a713866baec43f5af630c356ee
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/40255
Maintainer: Bobby R. Bruce <bbruce@ucdavis.edu>
Reviewed-by: Bobby R. Bruce <bbruce@ucdavis.edu>
Tested-by: kokoro <noreply+kokoro@google.com>
Previously we use attribute and event for communication between gem5
SimObject to systemC fastmodel sc_module. Creating a base class allows us
to perform casting once and get all the interface required. Also,
instead of warning on attribute not found, we should make simulator
panic if the sc_module does not provide the interface we need.
Change-Id: I91e1036cb792d556dfc4010e7a0f138b1519b079
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/40277
Reviewed-by: Gabe Black <gabe.black@gmail.com>
Maintainer: Gabe Black <gabe.black@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
The register cntfrq should be set to system counter frequency.
However, the current fastmodel implementation accidentally set it to
core frequency. This CL removes the wrong implementation, and real
cntfrq setting is performed in the initState.
Change-Id: I6c62822a4fbbcc0c499f79f6003dabb0c133f997
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/40276
Reviewed-by: Gabe Black <gabe.black@gmail.com>
Maintainer: Gabe Black <gabe.black@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>
