These are formatted as #defines, but they are actually enum constants.
If they were actually macros, they should use a GEM5_ prefix. Put them
in the gem5 namespace to remove the need for that prefix, and an auxv
namespace to remove the need for the AT prefix.
Since we now have a gem5::auxv namespace, move the AuxVector template
into it and deprecate the old, global namespace version.
Also, one of the constants was M5_BASE_PLATFORM, which was inconsistent
with the rest of the constants which were M5_AT_... This was not
actually because the constant in any header files was different, it was
just incorrectly transcribed and should have been M5_AT_BASE_PLATFORM.
Since we're changing names anyway, replace this with
gem5::auxv::BasePlatform.
Change-Id: Ie0dc34a683b113a4ed4bc76054eb822676f6e802
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/45242
Tested-by: kokoro <noreply+kokoro@google.com>
Maintainer: Gabe Black <gabe.black@gmail.com>
Reviewed-by: Daniel Carvalho <odanrc@yahoo.com.br>
Also add macros which define the old names to the new names for
backwards compatibility.
This change also takes the opportunity to rename the M5_ATTR_PACKED
macro to GEM5_PACKED, dropping the ATTR. None of the other attribute
based macros bother to specify that they stand for an attribute, making
this one inconsistent and overly verbose.
Similarly, it renames M5_NODISCARD to GEM5_NO_DISCARD to be consistent
with other macros which separate out individual words like GEM5_VAR_USED
and GEM5_NO_INLINE
Change-Id: I22d404492faf28b79a8247f869f14af21c9cf967
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/45230
Reviewed-by: Daniel Carvalho <odanrc@yahoo.com.br>
Maintainer: Gabe Black <gabe.black@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Rather than have a function with a if which checks against each
supported size of a type T which calls the right version of
swap_bytesNN, this change uses SFINAE and type traits to select the
function, and adds the requirement that the type being swapped is
actually convertible to the unsigned integer type of the appropriate
size.
This has the nice benefit of also avoiding hard coding which sizes can
be supported by the base swap_bytes, although that's probably not much a
limit in practice, avoids forcing all types to be convertible to all
sizes of uint*_ts for unused branches of the if, and removes a
dependence on base/logging.hh for the panic.
Change-Id: I2267f69a2868fcba2318c7562a49d27fef785395
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/45286
Reviewed-by: Daniel Carvalho <odanrc@yahoo.com.br>
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 should be either the fixed index if there are no predicated
operands (ie operands which may not be used), and an auto incrementing
index otherwise. This is still not bulletproof since the auto
incrementing index is just code which ++-es the index, and so the index
will be different and incremented each time that value is substituted
in.
Also, the mixture of predicated operands and the vector operands is
broken and will not generate compilable code, but I'm not going to try
to fix that here.
Change-Id: I1ceae519649762e54eaa019610e51bb8c21d28d6
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/42970
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Gabe Black <gabe.black@gmail.com>
Maintainer: Gabe Black <gabe.black@gmail.com>
These are currently only used in the reg, float and media ops, but
should be expanded to the other types eventually. This is part of an
attempt to use common machinery for the microops instead of having
each type recreate the mechanisms it needs locally.
Change-Id: I67f521b6b161310ba50a30ac4c73305cc75a63d5
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/42969
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Gabe Black <gabe.black@gmail.com>
Maintainer: Gabe Black <gabe.black@gmail.com>
Instead of having a bunch of implicit integer registers which are
identified only by number, except in the ISA description where there are
operands hard coded to certain numeric offsets into the implicit
registers, and having an independent count of those implicit registers,
just create a set of named indices for the registers we need.
Redefine NUM_INTREGS to be the total number of registers, and
NUM_ARCH_INTREGS to be the number of architectural integer registers.
Instead of using NUM_INTREGS as a coincidental short hand for the first
microop register (since that comes after the architectural ones), and
implicitly knowing that that's the zero register, define an INTREG_T0
constant which at least makes it clear what register we're talking
about, even if it's not clear that the semantics of that register make
it mostly a placeholder.
Change-Id: I5fa41169b9619ea68a50d6d5241ff9a07440bceb
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/42523
Reviewed-by: Gabe Black <gabe.black@gmail.com>
Maintainer: Gabe Black <gabe.black@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
A comment in that section of SConstruct talked about how ParseConfig
couldn't understand -Xlinker and -export-dynamic, and how that meant
they needed to parse the output of python-config manually. Some
searching around turned up this:
https://bugs.python.org/issue36508
which seems to suggest that exactly those two options weren't actually
supposed to be returned by python-config in the first place, and are
really for python's own internal build.
This change switches over to using ParseConfig, but to avoid bad options
sneaking through, it uses an option argument to ParseConfig to intervene
before the options are consumed and filter out everything except
required libraries, and library and header search directories.
Change-Id: I1a50eb030019a447b919381c32168fb3bb27b89b
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/40971
Reviewed-by: Gabe Black <gabe.black@gmail.com>
Reviewed-by: Bobby R. Bruce <bbruce@ucdavis.edu>
Maintainer: Gabe Black <gabe.black@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
These are HDF5, PNG, FENV, and TUNTAP support, all of which add
capabilities to gem5 which can be ignored if not wanted. It could be
argued that FENV changes behavior because it makes setting the FP
rounding mode work or not as used by SPARC, but since the difference is
trivial and in a niche area, that (along with the other options) doesn't
seem to justify having a top level control in the build system.
Since these are no longer options which say whether to *use* a
particular feature, and are instead flags which say whether we *have* a
particular feature, change their names from USE_* to HAVE_*, to stay
consistent with other variables.
Most of the remaining USE_* flags, KVM, FASTMODEL, SYSTEMC, and
(indirectly) USE_PYTHON, toggle on and off major systems which can have
a significant effect on boot time, or, in the case of FASTMODEL, even
consume external resources which may not be available and which may
break the build.
USE_POSIX_TIMER was also left alone since it selects between two
implementations of some functions. By forcing it to be on or off
depending on the host, we would be forcing some code to be excluded in
either case. That would make that other code impossible to test without
hacking up scons or modifying the host machine.
Change-Id: I0b03f23e65478caefd50cd3516974386e3dbf0db
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/40964
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>
Compound debug flags are intended to be a way to enable or disable a
group of simple debug flags at once, so that you don't need to enumerate
every more specialized flag in an area to get a broad amount of
debugging, nor do you give up the ability to select a general area
easily by making more specific flags.
It doesn't, however, make a lot of sense to check the value of a
compound debug flag, since it could be enabled but then have individual
subflags disabled. Exactly whether that means the compound flag should
be enabled or not is not clear, and figuring it out takes a fair amount
of work since each member simple flag needs to be visited.
Also, by having different behavior depending on the flag type, the
"enabled" method needed to be virtual.
This change eliminates the virtual method and moves the _tracing bool
member into the base class. If a subclass (only SimpleFlag currently)
wants to start or stop tracing based on itself, it should set or clear
this flag. Also, the "enabled" method has been renamed to "tracing",
since that's actually what it tracked. Being enabled by itself is not
sufficient to be tracing since there is also a global enable.
Finally, rather than duplicate the logic to convert a flag to bool in
the python wrapper, we can just use a cast to bool and take advantage of
the version in C++.
Change-Id: I3dc64c2364f0239294093686ddac6fcc8441f306
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/45007
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Gabe Black <gabe.black@gmail.com>
Maintainer: Gabe Black <gabe.black@gmail.com>
Instead of gating the behavior of DTRACE based on TRACING_ON in the
preprocessor, move it to C++. Beyond being a little simpler, this
ensures that the value of Debug::x is always valid (the proper header is
included, x is spelled correctly, etc) even if TRACING_ON is false.
Change-Id: Ie0085c0f8753ad5283ef1850d493706b977c21a8
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/45006
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Daniel Carvalho <odanrc@yahoo.com.br>
Maintainer: Jason Lowe-Power <power.jg@gmail.com>
