This avoids having to explicitly list the types that the result can
hold, avoiding having to specify what the vector types are. Also, the
variant type always has enough space for the result no matter what type
it is. For the "any" type, implementations are encouraged to not
dynamically allocate storage for small values (and RegVal == uint64_t
probably qualifies). This means that for the common case, RegVal, the
amount of storage will be smaller, and only when we actually need space
to store a VecRegContainer, etc, will that actually be allocated.
Change-Id: I43bf8d1866b1538db7d91cd9f1e635df642dd2c9
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/49130
Maintainer: Gabe Black <gabe.black@gmail.com>
Reviewed-by: Yu-hsin Wang <yuhsingw@google.com>
Tested-by: kokoro <noreply+kokoro@google.com>
In a few places, the makeSP helper function was being called on a fixed
register index, INTREG_SPX. That method would always return INTREG_SPX,
so this call was pointless.
Similarly, there were calls to makeZero on the fixed index INTREG_X31
which would return INTREG_ZERO.
It's not clear what the intention of this code was, so this change
simply removes the pointless calls, and makes it clearer what value is
actually being used by the instructions.
Change-Id: I604f013430f180566e1cc44939b145bc5f45f637
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/49763
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
Maintainer: Giacomo Travaglini <giacomo.travaglini@arm.com>
To bridge amba_pv::signal_master_port<bool> with IntPins, we made a
helper class for the purpose. The SignalSender class can be exported as
a gem5 Port, receive the signal, and transfer to fastmodel.
Here's an example showing how it works
*.lisa
```
component
{
slave port<Signal> reset;
}
```
evs.hh
```
class
{
SignalSender reset;
}
```
evs.cc
```
constructor(Params &p) : reset(p.name + ".reset", 0)
{
reset.signal_out.bind(Base::reset);
}
getPort
{
return reset;
}
```
Change-Id: I0936f9ebb2cd60e975661ae78e590285da697771
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/48943
Reviewed-by: Gabe Black <gabe.black@gmail.com>
Maintainer: Gabe Black <gabe.black@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
This register index was for an integer register which was just something
to return when the result should be thrown away. That's basically what
the zero register is/could already be used for. Replace INTREG_DUMMY
with INTREG_ZERO.
Also, change the type used for an index in SVE memory instructions from
IntRegIndex to RegIndex, since it's not actually storing an integer
register index, and g++ gets upset when you try to compare one against a
value which is out of range for that enum.
Change-Id: Ibdc488a2b55162a5f9e3d355126f6c48a99272a9
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/49223
Reviewed-by: Andreas Sandberg <andreas.sandberg@arm.com>
Reviewed-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
Maintainer: Giacomo Travaglini <giacomo.travaglini@arm.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Don't cache the first version requested of object files to use for
subsequent requests. This was originally put in place to avoid an error
when object files could be built with trivially different command lines,
ie command lines which are technically different but not in a
necessarily meaningful way, or less seriously a warning when the command
lines were the same.
The warning was disabled in an earlier change, and the error was avoided
by using a different object file suffix when building unit tests.
This helps avoid bugs if the object files actually *would* turn out to
be different in a meaningful way based on the flags used, and simplifies
the build.
Change-Id: I6b90e6e36b13adb73e587bb8fc533984f764d95a
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/48138
Reviewed-by: Jason Lowe-Power <power.jg@gmail.com>
Maintainer: Gabe Black <gabe.black@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
The systemc headers are supposed to be hermetic, so that they can be
included from generic systemc code without any dependency on the gem5
code base, at least when the systemc components are compiled, outside
of those header files themselves. It should be possible to copy the
"ext" directory out of the tree and make it available to systemc code,
and that code should be compileable.
Change-Id: Iec16a534ac04c7895cd8a30940b0acf64c257dde
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/49618
Maintainer: Bobby R. Bruce <bbruce@ucdavis.edu>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Gabe Black <gabe.black@gmail.com>
blobToCpp is called in two places, one which uses all its functionality,
and one which disables most of it. Instead, factor out the small core so
that it can be called directly by the call sight which uses only that
part, and blobToCpp itself.
This change also removes the ability to leave out a namespace or header
file code formatter, since the function is not called that way any more.
That simplifies blobToCpp significantly.
Change-Id: I63139311521bb4f9287fe41ff51e4e5301a18349
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/48135
Reviewed-by: Gabe Black <gabe.black@gmail.com>
Maintainer: Gabe Black <gabe.black@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Previously, the RISC-V devices queried the system object in
SimObject::init() for the number of CPUs and the number of threads.
However, the system object doesn't actually count the number of
CPUs/threads until it runs init(). Therefore, we've just been getting
lucky in the order that the SimObject init() functions were called.
This change instead decouples these two functions and makes the number
of CPUs/threads a parameter for the RISC-V interrupt devices. This
change also updates the example config script.
Change-Id: Ic4da5604156837cfeec05e58d188b42a02420de1
Signed-off-by: Jason Lowe-Power <jason@lowepower.com>
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/49431
Maintainer: Bobby R. Bruce <bbruce@ucdavis.edu>
Reviewed-by: Ayaz Akram <yazakram@ucdavis.edu>
Tested-by: kokoro <noreply+kokoro@google.com>
If given more than just its condition, gem5_assert will assume it
should act like chatty_assert.
Because we have our own custom assert now anyway, we can fold the
behavior of both into one macro and make life easier for users.
Deprecate chatty_assert.
Change-Id: I43497b5333802a265c0ad096681f64ab6f0424b1
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/48606
Maintainer: Gabe Black <gabe.black@gmail.com>
Maintainer: Bobby R. Bruce <bbruce@ucdavis.edu>
Reviewed-by: Bobby R. Bruce <bbruce@ucdavis.edu>
Tested-by: kokoro <noreply+kokoro@google.com>
This code will never be executed since FULL_SYSTEM is not part of the
build environment (and hasn't been for many years), and on top of that,
this declaration redundantly (and incompletely) tries to set up the
X86PagetableWalker that the ISA already sets up.
Change-Id: I40cffbd7f60c1f741b1a14d9009f80185c9ce28c
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/49405
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Matthew Poremba <matthew.poremba@amd.com>
Maintainer: Jason Lowe-Power <power.jg@gmail.com>
These now instantiate Builders for the protobuf .cc and .h files of the
right flavors, and install the .cc files as sources.
Also, this sets up the builder for .cc files so that it will know how to
build those files from .proto using the protobuf compiler. This is
optional, but will make it possible to pass .proto files in place of .cc
files or even object files as sources for other builders, and for scons
to figure out what chain of rules to use to get the desired results.
This is a step towards handing over more responsibility to scons and
eliminating at least some of our bespoke build code.
Change-Id: I7188a0917e999ad9148f7079830b2c26bcd563db
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/48134
Reviewed-by: Bobby R. Bruce <bbruce@ucdavis.edu>
Maintainer: Gabe Black <gabe.black@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
The "predicate"s for reading/writing some condition code registers were
written with constants which were built up from other constants which
represent individual bits in the condition code register. There are
existing constants which already exactly match those sets of bits, so we
can just use those instead of building up the same thing in-situ.
Change-Id: Iab5a5de04d0fd858414451531a357770ca9fde14
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/49244
Reviewed-by: Matt Sinclair <mattdsinclair@gmail.com>
Maintainer: Matt Sinclair <mattdsinclair@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Because MediaOps have two sizes, one for sources and one for
destinations, it does not have a single dataSize member to set the size
of its operands. This was difficult to correct at the time, so a
dataSize member was created which was fixed at 0, and the instructions
themselves would use srcSize and destSize internally to do the actual
computation.
That causes problems when tracing, since the printReg function needs to
know what size to use to print some registers properly, specifically
integer registers.
To now fix that problem, some SFINAE constructors have been added which
will either pass through a dataSize member if one exists, or pass
through a pointer to the instruction itself so that operand index
selector class can pick out the member that makes sense for it (destSize
for DestOp, srcSize for Src1Op and Src2Op).
Change-Id: I6b8259a5ab27f809b81453bcf987cc6d1be4811a
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/49203
Tested-by: kokoro <noreply+kokoro@google.com>
Maintainer: Gabe Black <gabe.black@gmail.com>
Reviewed-by: Matt Sinclair <mattdsinclair@gmail.com>
These methods are all identical now. The O3 versions can all be
consolidated into a single method. For the checker CPU, they can
actually be eliminated entirely, and the result queue's "emplace()"
method can be used to add items using less text than just calling the
original helper method.
Change-Id: Ifaeb3beeea257c8bbf951ee1dd8d2d5fd8bb3964
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/49128
Reviewed-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
Maintainer: Giacomo Travaglini <giacomo.travaglini@arm.com>
Tested-by: kokoro <noreply+kokoro@google.com>
These *used* to have a source register which was the syscall number.
That was not an actual property of the instruction, it was a property of
the syscall mechanism in Linux which had leaked into the implementation
of the instructions themselves.
That was corrected by removing that source register and letting the
syscall handling layer figure out which system call to invoke.
Unfortunately the SyscallInst format wasn't also updated, and when
printing the disassembly for those instructions, it would try to print
that source register. That instruction doesn't bother to set up a source
operand array since it doesn't actually have any, so that ended up
accessing random memory.
Change-Id: I20890ad69605983305a13f414ca59a5fa35d4d06
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/49183
Reviewed-by: Jason Lowe-Power <power.jg@gmail.com>
Maintainer: Jason Lowe-Power <power.jg@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
