i#5326: Partition AArch64 codec by ISA version

[AssadHashmi]

The current methods of defining and generating encode and decode
functionality are not scalable for implementing support of ISA
versions after v8.0

This patch splits up the codec.txt file into codec_<version>.txt files
and opnd_defs.txt. Generated code is now split out into ISA version
specific files.

Tests and related files have not been split up yet. That will happen
as part of new ISA version implementations.

Issue: #5326, #4393

[derekbruening]

Is there any plan to expose the ISA version in the IR interface? Would it be in the instruction structure, or all ISA version changes are assumed to be completely isolated by opcode (i.e., a version never adds a variant of an existing opcode) and it can be looked up purely from the opcode?

[AssadHashmi]

Is there any plan to expose the ISA version in the IR interface? Would it be in the instruction structure, or all ISA version changes are assumed to be completely isolated by opcode (i.e., a version never adds a variant of an existing opcode) and it can be looked up purely from the opcode?

There is no immediate plan to expose version information in the IR just yet, at least for the upcoming v8.1 and v8.2 work.

However when we implement SVE I think we will need to have some form of version/feature information as part of the codec's capability. This is because each vendor's implementations of SVE have some non-SVE version based features which vary between vendors.

It's worth highlighting the subtle distinction between Arm's "versions" (v8.n, v9.m) and "features" (FEAT_x, FEAT_y).

When Arm releases a version for the architecture it specifies optional features and mandatory features. Conformant hardware has to implement the mandatory features for the supported version but is free to select whichever optional features it wants from whichever version.

For strict accuracy, hardware shouldn't be defined by version but a feature list. In practice people tend to use the version which most closely matches the feature list, because it's just shorter and easier.

This can be confusing because saying:
"This hardware supports version v8.n."
actually means:
"This hardware supports the mandatory features of v8.n and the following optional features of version v8.n, v8.m etc."

The consequences of this for us are that:

• The version in which a mandatory feature first appears will be included in codec_<version>.txt
• The version in which an optional feature first appears will be included in codec_<version>.txt even if it can be part of other versions' implementations.
• When we do add ISA version information we should make the FEAT_ of the opcode part of the instruction structure.

At runtime we can read the features registers which will enable DR to distinguish between app instructions not supported by hardware but supported by DR and vice-versa.