This has two purposes. First, SCons assumes that once you call
Configure, you won't set up the environment the Configure is based on
until after you get the environment back from it again with
conf.Finish(). We get away with this when the cache mode for config
tests is not "force", since Configure just reuses the environment we
pass in, and any changes we make are immediately communicated between
the two.
If the cache mode *is* "force" though, SCons modifies the decider so
that everything the conf environment goes to build looks like it's out
of date. It does that by cloning the original environment, and then
using that clone to do its tests. That causes a problem because we have
a long lived "conf" object and make further changes to main, and since
the two environments are now separate the one in conf doesn't see those
updates.
Second, and more subtly, we export our "main" and "env" environments so
that other SConsopts and SConscript files can use them and define things
in them. The way Configure is designed, if the config caching mode is
"force", then it will create a new environment, and then that
environment will replace what the, for instance, "main" variable points
to when "main = conf.Finish()" is executed.
Unfortunately, if we've already Export()-ed main, we've exported what
the "main" variable pointed to at that time. Our view of "main" will
track with the value that conf.Finish() returned, but since that
construction environment is mearly derived from the main we Exported and
not actually the same thing, they have diverged at that point and will
behave independently.
To solve both of these problems, this change modifies the
gem5_scons.Configure() method so that it's a context manager instead of
a regular function. As before, it will call Configure for us and create
a configuration context, which it will yield as the "with" value. When
the context exits, all the variables in the context Finish() returns
will be shoved back into the original context with Replace(). This isn't
perfect since variables which were deleted in the environment (probably
very rare in practice) will not exist and so will not overwrite the
still existent variable in the original dict.
This has several advantages. The environment never splits into two
copies which continue on independently. It makes the lifetime of a
configuration context short, which is good because behavior during that
time is tricky and unintuitive. It also makes the scope of the context
very clear, so that you won't miss the fact that you're in a special
setting and need to pay attention to what environment you're modifying.
Also, this keeps the conceptual overhead of configuration localized to
where the configuration is happening. In parts of the SConscripts which
are not doing anything with conf, etc, they don't have to modify their
behavior since no configuration context is active.
This change is based on this change from Hanhwi Jang who identified this
problem and proposed an initial solution:
https://gem5-review.googlesource.com/c/public/gem5/+/44265
Change-Id: Iae0a292d6b375c5da98619f31392ca1de6216fcd
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/44389
Reviewed-by: Daniel Carvalho <odanrc@yahoo.com.br>
Reviewed-by: Hanhwi Jang <jang.hanhwi@gmail.com>
Maintainer: Bobby R. Bruce <bbruce@ucdavis.edu>
Tested-by: kokoro <noreply+kokoro@google.com>
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>
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 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>
The unnecessary DependenceTags is already being removed by another
pending change, and so is left in place for that to remove. Once that's
happened, the regs/*.hh includes can be removed, and there may be other
include related tangles to sort out.
Change-Id: I1c02aa8fd2f2045017609b70523b3519c2a92b03
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/41742
Maintainer: Bobby R. Bruce <bbruce@ucdavis.edu>
Reviewed-by: Gabe Black <gabe.black@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
The SouthBridge used to have a parameter to point back at a Platform
object which it would dynamically cast to the Pc platform type, and it
would use that to tell the Pc platform where it was. The Pc platform
would then configure initial values in the SouthBridge during the init
phase. Now, the Pc platform has a parameter which by default
instantiates a SouthBridge, so that it will have a pointer
automatically. The Pc object knows it will have a SouthBridge, and now
the SouthBridge no longer has to assume that it's housed inside a Pc
platform.
Also, the SouthBridge device had instantiated a lot of child objects,
and then to ensure that they were accessible in c++, they were also set
as parameters on the object. Now, these children are created as the
default value for those parameters. They no longer have to be declared
and then separately hooked up as parameters. They could also
theoretically be replaced more easily since they're now only defaults,
although in practice that's unlikely.
Change-Id: I296b18a55ab6aedbb609ca4f545f7b19c21fd905
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/43886
Reviewed-by: Hoa Nguyen <hoanguyen@ucdavis.edu>
Maintainer: Gabe Black <gabe.black@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
This class, because it inherits from AddrMapper, would only poke its
upstream port to let it know to request its address range if it's
downstream port had asked it to. This doesn't make sense, since the
RangeAddrMapper has a fixed range it will respond to. Also, when the
RangeAddrMapper is notified that it's downstream port has an updated
range, the mapper should request that range and make sure all of the
addresses it will output are in the range the other object expects.
Change-Id: I57b558644b103822a9af53733bdb8518836ef5de
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/43346
Reviewed-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
Maintainer: Giacomo Travaglini <giacomo.travaglini@arm.com>
Tested-by: kokoro <noreply+kokoro@google.com>
