The line of code which would have added the null SimObject as a child
was already guarded by an if, but the line before it which would set the
parent of the null SimObject itself was not. This change moves it into
the if as well.
Change-Id: Icfbc0e87e0ab55917735f720de4e94c19185df46
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/44387
Reviewed-by: Daniel Carvalho <odanrc@yahoo.com.br>
Maintainer: Gabe Black <gabe.black@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
The SimObject will have already been added to the other object's list
of children, and if it's given a new parent, it will be added as a
child to the new parent as well. The object will then be the child of
two other SimObjects which will cause a delightful variety of hard to
debug problems.
Another slightly better way to handle this situation would be to both
move to the new parent and also remove the SimObject from the original
parent's list of children. Unfortunately there isn't a simple way to
figure out what the parent called the child, and so we would have to
look through its children one by one until we found the right one.
Change-Id: I8f43dfab7adf58a43f806390a0c7c35a2efde11a
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/43905
Reviewed-by: Daniel Carvalho <odanrc@yahoo.com.br>
Reviewed-by: Jason Lowe-Power <power.jg@gmail.com>
Maintainer: Gabe Black <gabe.black@gmail.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>
The VExpress_GEM5_Foundation platform was reserving
a region of the memory map (@ 0x4 0000 0000) for PCI.
The Armv8-A FVP Foundation platform is not PCI capable at
the moment, so any PCI logic is really gem5 specific.
With this patch we are aligning gem5 to the FVP Base Platform,
which supports PCI and it is reserving 256GiB of memory
starting at 0x40 0000 0000 (256GiB).
Fast Models - Reference Manual - Version 11.8
At the moment we are still supporting a single DRAM range,
starting at 2GiB. So DRAM could overlap with the PCI memory
region though it is unlikely to happen in near future as
it would require a DRAM size > 254 GiB.
JIRA: https://gem5.atlassian.net/browse/GEM5-898
Change-Id: I506fd6696cdddc39d057602581cb16b30db3f7c7
Signed-off-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/44165
Maintainer: Bobby R. Bruce <bbruce@ucdavis.edu>
Maintainer: Andreas Sandberg <andreas.sandberg@arm.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Andreas Sandberg <andreas.sandberg@arm.com>
1 - Rename the verifier from ClassBraces to
StructureBraces.
2 - Add support for anonymous structures. This
includes anonymous classes, anonymous structs,
anonymous enums and anonymous unions. e.g.:
struct {
3 - Make the verifier not trigger error for
structures that do not currently abide to gem5's
coding style and use non-uppercase characters as
their first character. e.g.:
struct test {
4 - Improve handling of nested structures. e.g.:
struct { enum { VAR, VAR2
becomes
struct
{
enum {
VAR, VAR2
But the verifier will fail for declarations like:
struct { int a; }; struct {
which becomes
struct
{
int a; struct {
However, this later issue is not a desired coding
style, so it should be handled by another kind of
verifier if desired.
Change-Id: I8f0536dcc2c164e2d3d2a2e5b7a35d5ee351a814
Signed-off-by: Daniel R. Carvalho <odanrc@yahoo.com.br>
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/43365
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Gabe Black <gabe.black@gmail.com>
Reviewed-by: Bobby R. Bruce <bbruce@ucdavis.edu>
Maintainer: Gabe Black <gabe.black@gmail.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>
This option would set the -msse2 compiler flag to avoid using x87
floating point, but every 64 bit x86 CPU supports sse2, and so sse2 is
enabled by default on compilers targeting it. 32 bit x86 CPUs are
obscure enough that it's not worth preserving this marginally meaningful
option which would only matter for them.
Change-Id: Ib425c261b27f1f74300e714619787d04970065ce
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/40879
Reviewed-by: Gabe Black <gabe.black@gmail.com>
Maintainer: Gabe Black <gabe.black@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
An expression in that library intended to create a bitmask by checking
if a bit should be set, and then using ?: to select between a bitmask
with that bit, or 0. Unfortunately | is higher precedence than ?:, and
so 0 would be |-ed with the condition of the next ?: instead. This CL
fixes the bug by adding some parenthesis.
Change-Id: Ib7e06f261e07a6ad00b9a96939d07b64c3a50409
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/40954
Reviewed-by: Gabe Black <gabe.black@gmail.com>
Maintainer: Gabe Black <gabe.black@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
This flag was necessary because of self assignments in the ISA parser
where self assignments are often hints to the parser itself, and in one
case because a pybind-ism used to attach the -= operator looked like a
self assignment.
This change narrows the scope of the flag that disables this warning to
only files generated by the ISA parser, and the single file in the
systemc code which uses that operator overload.
Change-Id: Ib64fc72e46f894cba9064afcdbdcc5859c30e745
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/40952
Reviewed-by: Gabe Black <gabe.black@gmail.com>
Maintainer: Gabe Black <gabe.black@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
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: Ic5cc32773652f423e66d78f31b80c6604f2c4a49
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/41214
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Andreas Sandberg <andreas.sandberg@arm.com>
Maintainer: Andreas Sandberg <andreas.sandberg@arm.com>
Use SConsopts files local to individual domains to pull
non-foundational build code out of SConstruct. This greatly simplifies
SConstruct, and also makes it easier to find build configuration having
to do with particular pieces of gem5.
This change also converts some python level variables, all_protocols,
protocol_dirs, and slicc_includes, into the environment where the timing
of their initialization is more flexible.
Change-Id: Ie61ceb75ae9e5557cc400603c972a9582e99c1ea
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/40872
Maintainer: Gabe Black <gabe.black@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Gabe Black <gabe.black@gmail.com>
Don't use the "E" tag when there is only a register or memory based
version of the instruction, since that decodes to both. Don't special
case the "st(1)" version of an instruction if it's just a matter of the
assembly syntax and not the instruction encoding. Don't decode based on
Mod, and then use the tag type "E" which will again decode on Mod, use
"E" for both the memory and register versions at the same time. Set the
default instruction to Inst::UD2 so that we don't have to specify it as
the default locally in each decode block. Let the "M" tag handle the Mod
= 3 case, which is built into that operand type. That's slightly
inconsistent with the "R" type which does not handle the "not 3" case,
but we can take advantage of it none the less.
There are instructions which, when decoded as the Inst format, will take
the "M" type tag and be able to drop their decoding of the Mod = 3 case,
but since they aren't Inst right now and can't sub-decode Mod on their
own, the 3 case needs to stay for now.
In most cases when dealing with x87 registers, the "dataSize" argument
to microops doesn't matter since the size doesn't change. There may be
an opportunity to consolidate the various FP microops and use dataSize
= 10 for x87 registers, although there are some nuances there that may
make that not work out.
Change-Id: Ia3ff6176796af66f6a3c463b538e750e65893a84
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/42904
Maintainer: Bobby R. Bruce <bbruce@ucdavis.edu>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Gabe Black <gabe.black@gmail.com>
This unused pair of methods could be used to trigger a breakpoint within
the remote GDB stub, but was unused and would need to be called from an
instance of GDB attached to gem5 itself.
The system's version of breakpoint was also limitted in that it would
only cause a breakpoint in the first thread's GDB and no other.
Change-Id: I53ceab78667610177dbb8be1def3a88262befeec
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/44031
Reviewed-by: Boris Shingarov <shingarov@gmail.com>
Reviewed-by: Daniel Carvalho <odanrc@yahoo.com.br>
Maintainer: Gabe Black <gabe.black@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
This commit removes functions that indexed into the
vectors that held the operands. Instead, for-each loops
are used, iterating through one of 6 vectors
(src, dst, srcScalar, srcVec, dstScalar, dstVec)
that all hold various (potentially overlapping)
combinations of the operands.
Change-Id: Ia3a857c8f6675be86c51ba2f77e3d85bfea9ffdb
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/42212
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Matt Sinclair <mattdsinclair@gmail.com>
Maintainer: Matt Sinclair <mattdsinclair@gmail.com>
This change removes the GPUDynInstPtr argument from
getRegisterIndex(). The dynamic inst was only needed
to get access to its parent WF's state so it could
determine the number of scalar registers the wave was
allocated. However, we can simply pass the number of
scalar registers directly. This cuts down on shared
pointer usage.
Change-Id: I29ab8d9a3de1f8b82b820ef421fc653284567c65
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/42210
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Matt Sinclair <mattdsinclair@gmail.com>
Maintainer: Matt Sinclair <mattdsinclair@gmail.com>
