An example case,
```python
mem_side_port = RequestPort(
"This port sends requests and " "receives responses"
)
```
This is the residue of running the python formatter.
This is done by finding all tokens matching the regex `"\s"(?![.;"])`
and manually replacing them by empty strings.
Change-Id: Icf223bbe889e5fa5749a81ef77aa6e721f38b549
Signed-off-by: Hoa Nguyen <hoanguyen@ucdavis.edu>
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/66111
Reviewed-by: Bobby Bruce <bbruce@ucdavis.edu>
Maintainer: Bobby Bruce <bbruce@ucdavis.edu>
Tested-by: kokoro <noreply+kokoro@google.com>
Clang Version 14 throws a warning "use of bitwise '&/|' with boolean
operands" for cases where bitwise operations are used where boolean
operations are intended.
This occurred in "WriteMast.hh", "data.isa", and "decode.cc" where
boolean values were being compared using the bitwise operands. While
bitwise operations are equivalent, they have been changed to boolean
operations in this patch to avoid the clang-14 warning.
Change-Id: Ic7583e13a325661712c75c8e1b234c4878832352
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/64172
Reviewed-by: Tom Rollet <tom.rollet@huawei.com>
Reviewed-by: Kunal Pai <kunpai@ucdavis.edu>
Maintainer: Bobby Bruce <bbruce@ucdavis.edu>
Tested-by: kokoro <noreply+kokoro@google.com>
The KVM_ISA setting was moved into a CONF dict, but the code which
ensured it had a default if there was no possible KVM hosting ISA was
still setting that variable in the base environment dict. This moves
the setting into the CONF dict instead.
Change-Id: I067c969dd761b2cdb098bcba6cd6a4b643d2d427
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/63752
Reviewed-by: Earl Ou <shunhsingou@google.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Maintainer: Gabe Black <gabeblack@google.com>
Add control/branch instructions committed stat to Minor CPU. The stats
can be found in board.processor.cores.core.committedControl_0 in
stats.txt. The stats counted are IsControl, IsDirectControl,
IsIndirectControl, IsCondControl, IsUncondControl, IsCall, and IsReturn.
IsControl tracks the total control/branch instructions committed.
Use inst->staticInst->isControl() flag to determine if an instruction is
a control or not, and then using other flags in the StaticInstFlags to
determine the type of control instruction and tracking the committed
ones.
Jira Issue: https://gem5.atlassian.net/browse/GEM5-1283
Change-Id: Iee1010fdf0fa4078ebe1c56b437295abdb5f4469
Co-authored-by: Kunal Pai <kunpai@ucdavis.edu>
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/63358
Reviewed-by: Jason Lowe-Power <power.jg@gmail.com>
Reviewed-by: ZHENGRONG WANG <seanyukigeek@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Maintainer: Jason Lowe-Power <power.jg@gmail.com>
The way these were set up, there would be a conflict between SimObject
files with the same name set up for different ISAs.
This change creates a single file which tries to determine how many ISAs
are enabled, and if there is exactly one, it creates a backwards
compatible alias for the ISA specific CPU types.
Change-Id: Iab358c2880d49222e814a98354c81d0f306fe1fc
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/52493
Reviewed-by: Andreas Sandberg <andreas.sandberg@arm.com>
Maintainer: Gabe Black <gabe.black@gmail.com>
Reviewed-by: Gabe Black <gabe.black@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Maintainer: Andreas Sandberg <andreas.sandberg@arm.com>
The TARGET_ISA variable would let you select one ISA from a list of
possible ISAs. That has now been replaced with USE_ARM_ISA, USE_X86_ISA,
etc, variables which are boolean on or off. That will allow any number
of ISAs to be enabled or disabled individually. Enabling something other
than exactly one of these will probably prevent you from getting a
working gem5 binary, but those problems are being addressed in other,
parallel change series.
I decided to use the USE_ prefix since it was consistent with most other
on/off variables we have in gem5. One noteable exception is the
BUILD_GPU setting which, you could convincingly argue, is a better
prefix than USE_. Another option would be to use CONFIG_, in
anticipation of using a kconfig style config mechanism in gem5.
It seemed premature to start using a CONFIG_ prefix here, and if we
decide to switch to some other prefix like BUILD_, it should be a
purposeful choice and not something somebody just starts using.
Change-Id: I90fef2835aa4712782e6c1313fbf564d0ed45538
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/52491
Tested-by: kokoro <noreply+kokoro@google.com>
Maintainer: Gabe Black <gabe.black@gmail.com>
Reviewed-by: Jason Lowe-Power <power.jg@gmail.com>
Reviewed-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
This makes RegIds and the RegClass-es associated with them responsible
for their own flattening. If they don't need to be flattened (a common
case) then they just mark themselves as already flat and that step can
be skipped.
This will also make it possible to get rid of the (get|set)RegFlat APIs,
since if you want to use flattened registers, you'll either have or
create a flattened RegId and pass it into the same (get|set)Reg method.
By making flattening work on RegIds instead of RegIndexes, this will
also make it possible for registers to start out in one RegClass and
move into another one. This would be useful if, for instance, there were
multiple groups of integer registers which had different indexing
semantics, but which should all end up in the same pool for renaming.
For instance, on x86, there are three distinct classes of FP registers.
They are the MMX registers, the pairs of registers which back the XMM
registers, and the X87 registers. Only the last of these needs
flattening. These could all be treated as different RegClass-es
pre-flattening, and could converge on the underlying floating point
register file post-flattening.
Another example in x86 is that some registers can encode that they
should refer to either the first byte of one register, or the second
byte of another register. This only applies to some registers though,
and so only those would need to go through the flattening step.
Another major advantage is that this removes the need for flattening
functions on the ISA object. Having those, and treating the ISA object
as a TheISA::ISA instead of the more generic BaseISA, was done to make
the flattening functions inline, and to make them fold away in cases
where flattening is not necessary. This new scheme isn't *quite* as
streamline as that, since you'll actually need to check if something is
already flattened. You won't, however, need to check what type the
register is and then look up the right flattening function, so that will
likely compensate.
Change-Id: I3c648cc8c0776b0e1020504113445b7d033e665f
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/51227
Maintainer: Gabe Black <gabe.black@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
The InstResult class is always used to store a register value, and also
only used to store a RegVal and not any more complex type like a
VecRegContainer. This is partially because the methods that *would*
store a complex result only have a pointer to work with, and don't have
a type to cast to to store the result in the InstResult.
This change reworks the InstResult class to hold the RegClass the
register goes with, and also either a standard RegVal, or a pointer to a
blob of memory holding the actual value if RegVal isn't appropriate. If
the InstResult has no RegClass, it is considered invalid.
To make working with InstResult easier, it also now has an "asString"
method which will just call into the RegClass's valString method with
the appropriate pointer.
By removing the ultimately unnecessary generality of the original class,
this change also simplifies InstResult significantly.
Change-Id: I71ace4da6c99b5dd82757e5365c493d795496fe5
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/50253
Maintainer: Gabe Black <gabe.black@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
Replace the two constructors with one that takes the truly mandantory
parameters, and then a function to derive a new RegClass with some sort
of adjustment, currently by adding custom ops, or setting a non-standard
register size.
Because the constructor and the modifier function are constexpr, they
should fold away and not actually create extra temporary copies of the
RegClass in the modifier functions.
Change-Id: I8acb755eb28fc8474ec453c51ad205a52eed9a8e
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/50249
Tested-by: kokoro <noreply+kokoro@google.com>
Maintainer: Giacomo Travaglini <giacomo.travaglini@arm.com>
Reviewed-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
Now that we have a pointer to the actual RegClass the RegId is
associated with, we can use it's regName method to pretty print the
RegId for us. This gets rid of the redundant print method for RegId.
Also, replace the default register printing method with the
implementation in the << operator, which is more descriptive.
Change-Id: I00e93032ddea77e167ca13e54b370de7210f1a2b
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/49808
Maintainer: Giacomo Travaglini <giacomo.travaglini@arm.com>
Reviewed-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Make it possible to read any type of reg, assuming it fits in a RegVal.
This avoids assuming building in a dependency on the readIntReg
accessor.
It also avoids setting up a situation where the API could at least
theoretically base the timing expression on the value of *any* int reg,
even ones the instruction does not interact with. The ...ReadIntReg
expression was only ever used with the result of the ...SrcReg
expression, and in my opinion, that's realy the only way it makes sense
to use it. It doesn't seem useful to split that operation into two
parts.
If it actually does make sense (although I doubt this), these operations
can't really be generalized easily since the TimingExpr... classes all
expect to pass around uint64_ts, and a RegId, the *real* value of a
SrcReg index which does not assume a register type, would not fit in
that in the general case.
Change-Id: I253a0a058dc078deeb28ef0babead4c8ffc3b792
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/49776
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
Maintainer: Gabe Black <gabe.black@gmail.com>
That will let a RegId be used where a RegId is required, but also let it
be downconverted into a scalar RegIndex if using an older API. Note that
this does *not* let you automatically upconvert from a RegIndex into a
RegId, since there would be no way to know what class of register to
use.
Change-Id: I5fff224dce5e02959d5fc3e717014bf7eaa9c022
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/49753
Tested-by: kokoro <noreply+kokoro@google.com>
Maintainer: Giacomo Travaglini <giacomo.travaglini@arm.com>
Reviewed-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
