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>
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>
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>
