These correspond to the existing operand types like IntRegOperand, or as
it's called in the operand table 'IntReg'. These subclasses
automatically set the base type name ('IntReg' for IntRegOperands),
which results in some mildly more familiar looking syntax, but is still
not that different from what we have today.
Change-Id: Id77c4e5a5e1b93c10aa9ad85e1a615f6c145832a
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/49725
Reviewed-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
Maintainer: Giacomo Travaglini <giacomo.travaglini@arm.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Currently, to specify operands for an ISA, you define a dict from
operand names to properties in the ISA description. The properties are
in a list which has well defined positions for each entry, some of which
are optional.
These lists are fairly opaque since they don't have any way to, for
instance, accept keyword arguments. Also, these specifications simply
list as their first element what type of operand they're going to be.
This change is the first step in turning these specifications into
something more robust like a small temporary object. This object can be
constructed from a class which has a proper constructor that can take
keyword arguments, can have defaults, and can be subclassed.
Change-Id: I5f24d0b41f3e30b24a1ddd10157965d700d6c906
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/49724
Reviewed-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
Maintainer: Giacomo Travaglini <giacomo.travaglini@arm.com>
Tested-by: kokoro <noreply+kokoro@google.com>
These methods were all identical, except that IntRegOperand and
CCRegOperand classes had logic to handle operand predication. Since the
other operand types won't have predicates set, we can use the superset
version, and the other types will reduce to what they used to in
practice.
Change-Id: I51eeedcacb7cfc6e2c136742701ee9bf80ec4e15
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/49721
Reviewed-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
Maintainer: Giacomo Travaglini <giacomo.travaglini@arm.com>
Tested-by: kokoro <noreply+kokoro@google.com>
There are a number of operand types which are registers. Define a
RegOperand type which they can all inherit from to get register generic
functionality. This will also become a way to add generic register types
with malleable properties at the ISA level.
Change-Id: I01a1d5d133d8f64106d005a744631f64e6808e57
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/49719
Reviewed-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
Maintainer: Giacomo Travaglini <giacomo.travaglini@arm.com>
Tested-by: kokoro <noreply+kokoro@google.com>
These registers used to be accessed with a two dimensional index, with
one dimension specifying the register, and the second index specifying
the element within that register. This change linearizes that index down
to one dimension, where the elements of each register are laid out one
after the other in sequence.
Change-Id: I41110f57b505679a327108369db61c826d24922e
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/49148
Reviewed-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
Maintainer: Giacomo Travaglini <giacomo.travaglini@arm.com>
Tested-by: kokoro <noreply+kokoro@google.com>
When calling a method in a superclass, you can/should use the super()
method to get a reference to that class. The python 2 version of that
method takes two parameters, the current class name, and the "self"
instance. The python 3 version takes no arguments. This is better for a
at least three reasons.
First, this version is less verbose because you don't have to specify
any arguments.
Second, you don't have to remember which argument goes where (I always
have to look it up), and you can't accidentally use the wrong class
name, or forget to update it if you copy code from a different class.
Third, this version will work correctly if you use a class decorator.
I don't know exactly how the mechanics of this work, but it is referred
to in a comment on this stackoverflow question:
https://stackoverflow.com/questions/681953/how-to-decorate-a-class
Change-Id: I427737c8f767e80da86cd245642e3b057121bc3b
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/52224
Reviewed-by: Gabe Black <gabe.black@gmail.com>
Maintainer: Gabe Black <gabe.black@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Apply the gem5 namespace to the codebase.
Some anonymous namespaces could theoretically be removed,
but since this change's main goal was to keep conflicts
at a minimum, it was decided not to modify much the
general shape of the files.
A few missing comments of the form "// namespace X" that
occurred before the newly added "} // namespace gem5"
have been added for consistency.
std out should not be included in the gem5 namespace, so
they weren't.
ProtoMessage has not been included in the gem5 namespace,
since I'm not familiar with how proto works.
Regarding the SystemC files, although they belong to gem5,
they actually perform integration between gem5 and SystemC;
therefore, it deserved its own separate namespace.
Files that are automatically generated have been included
in the gem5 namespace.
The .isa files currently are limited to a single namespace.
This limitation should be later removed to make it easier
to accomodate a better API.
Regarding the files in util, gem5:: was prepended where
suitable. Notice that this patch was tested as much as
possible given that most of these were already not
previously compiling.
Change-Id: Ia53d404ec79c46edaa98f654e23bc3b0e179fe2d
Signed-off-by: Daniel R. Carvalho <odanrc@yahoo.com.br>
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/46323
Maintainer: Bobby R. Bruce <bbruce@ucdavis.edu>
Reviewed-by: Bobby R. Bruce <bbruce@ucdavis.edu>
Reviewed-by: Matthew Poremba <matthew.poremba@amd.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>
This code was simplified a little while ago, and the wrong variable name
was used in that computation accidentally. Fortunately the "wrong" value
would be too large, and so nothing bad would happen except a pair of
arrays would be overly large in the O3 instruction class.
Change-Id: I9694f1a8c79a62a172ef63bdd2f98fa0ace06acd
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/38383
Reviewed-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
Maintainer: Giacomo Travaglini <giacomo.travaglini@arm.com>
Tested-by: kokoro <noreply+kokoro@google.com>
When parsing an ISA description, the InstObjParams class needs to have a
reference to the current parser. It does that by exposing a wrapper to
the description rather than the actual InstObjParams class. That wrapper
injects an additional argument into the InstObjParams constructor.
Originally, the wrapper which injectect the additional argument was a
function which masqueraded as a class. That made it impossible to
subclass InstObjParams.
Instead, this change replaces that function wrapper with a class
wrapper, and injects the extra argument in the __init__ method. This
preserves the fact that the InstObjParams name refers to a class, and
allows any sort of interaction that's normally allowed with a class like
subclassing.
Change-Id: I550ea2e60eadac3c7c0b9afa7d71f4607b49a5d2
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/39275
Reviewed-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
Maintainer: Giacomo Travaglini <giacomo.travaglini@arm.com>
Tested-by: kokoro <noreply+kokoro@google.com>
ARM reaches in and pads out the source register index list behind the
parser's back to force dest regs to also be sources in case an
instruction fails predication and needs to forward the original register
values. It shouldn't be hacking up these values in that way, but since
it is, this will let it continue to do so while still fitting in the new
system where each instruction allocates its src/dest reg index arrays to
size.
Change-Id: Ia296be9f63123f18f6cdc0d3bb1314d33e759b3a
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/38380
Reviewed-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
Maintainer: Giacomo Travaglini <giacomo.travaglini@arm.com>
Tested-by: kokoro <noreply+kokoro@google.com>
There are two new strings, reg_idx_arr_decl which declares the source
and dest register index arrays, and set_reg_idx_arr which installs them
in the base class.
The set_reg_idx_arr code needs to implicitly figure out what type to use
based on the type of the "this" pointer. The name of the containing
class is not *necessarily* the same as class_name, since the generated
code can use that name, something based on that name, or whatever else
it wants. No other format string (other than class_name itself) uses the
class name internally, so we can't count on that working in existing ISA
definitions.
Change-Id: Id995a46896e71a2fcf3103c34a1e1e67e24f88f4
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/36878
Reviewed-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
Maintainer: Giacomo Travaglini <giacomo.travaglini@arm.com>
Tested-by: kokoro <noreply+kokoro@google.com>
There were accessors for reading these indexes, but they were not
consistently used. This change makes them private to StaticInst, and
changes places that were accessing them directly to instead use the
accessors. New accessors are added for code generated by the ISA parser
and some ARM code to set the indexes without accessing them directly.
By forcing these values to be behind accessors, it will be much simpler
to change how those values are stored and retrieved.
Change-Id: Icca80023d7f89e29504fac6b194881f88aedeec2
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/36875
Reviewed-by: Andreas Sandberg <andreas.sandberg@arm.com>
Maintainer: Andreas Sandberg <andreas.sandberg@arm.com>
Tested-by: kokoro <noreply+kokoro@google.com>