Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Finish AArch64 encoder/decoder #2626

Open
Tracked by #5145
egrimley opened this issue Aug 30, 2017 · 9 comments
Open
Tracked by #5145

Finish AArch64 encoder/decoder #2626

egrimley opened this issue Aug 30, 2017 · 9 comments

Comments

@egrimley
Copy link
Contributor

https://github.com/DynamoRIO/dynamorio/wiki/AArch64-Port: "At the end of 2016, DynamoRIO's encoder/decoder handles all the load/store instructions, including load/store of FP/SIMD registers, and all the instructions that do not operate on FP/SIMD registers, up to ARMv8.2."

The non-load/store FP/SIMD instructions should be added.

See #1569, #2440 and #2443.

@egrimley
Copy link
Contributor Author

I'll just mention something here that I don't think is stated anywhere else:

The OP_xx trick, decoding an unrecognised instruction in a defensive way, guessing that it might read and write the general-purpose registers referenced in the four places in the instruction word where the number of a general-purpose register typically appears, should perhaps be retained, at least as on option, even when the decoder is believed to be complete. It would let DynamoRIO correctly handle, in many cases, instructions that have been added to the architecture since DynamoRIO's decoder was last updated.

@fhahn fhahn self-assigned this Jan 18, 2018
fhahn added a commit that referenced this issue Jan 19, 2018
This adds encoding and decoding support the scalar and vector versions
of FADD. The patterns are auto-generated using the publicly
available ISA spec from
https://alastairreid.github.io/ARM-v8a-xml-release/.

For the scalar versions, the H,S and D registers are used to generate
the correct encoding. For the vector versions, the newly added V64
register is used for 64 bit wide vector operands and Q for 128 bit wide
vectors. We can re-use Q, as no scalar version of FP instructions
should use Q registers. But it might be better to add a V128 register
class for 128 bit wide vectors.

The element size for single/double is encoded as the fsz operand.
Without fsz operand, fp16 is assumed (added in Arm v8.2).

Issue: #2626
Change-Id: I141f950a45d5e1390b7c2dae8e1ea3de5bd6070e
fhahn added a commit that referenced this issue Jan 19, 2018
This patch adds support for vector arithmetic instructions where all
operands are vector registers of the same size.

The patterns are auto-generated using the publicly available ISA spec
from https://alastairreid.github.io/ARM-v8a-xml-release/.

Issue: #2626
Change-Id: Iaf38fa73765192931ea2ccd3817d25be03c9bf5a
fhahn added a commit that referenced this issue Jan 19, 2018
This adds encoding and decoding support the scalar and vector versions
of FADD. The patterns are auto-generated using the publicly
available ISA spec from
https://alastairreid.github.io/ARM-v8a-xml-release/.

For the scalar versions, the H,S and D registers are used to generate
the correct encoding. For the vector versions, the newly added V64
register is used for 64 bit wide vector operands and Q for 128 bit wide
vectors. We can re-use Q, as no scalar version of FP instructions
should use Q registers. But it might be better to add a V128 register
class for 128 bit wide vectors.

The element size for single/double is encoded as the fsz operand.
Without fsz operand, fp16 is assumed (added in Arm v8.2).

Issue: #2626
Change-Id: I141f950a45d5e1390b7c2dae8e1ea3de5bd6070e
fhahn added a commit that referenced this issue Feb 13, 2018
This adds encoding and decoding support the scalar and vector versions
of FADD. The patterns are auto-generated using the publicly available
ISA spec from
https://developer.arm.com/products/architecture/a-profile/exploration-tools

For the scalar versions, the H, S and D registers are used to generate
the correct encoding. For the vector versions, D and Q registers are
used to denote the vector width. They also take an additional immediate
as source operand, which denotes the element width (half, single or 
double).

Issue: #2626
fhahn added a commit that referenced this issue Apr 24, 2018
This patch adds encoding & decoding support for most arithmetic FP Neon
instructions. The structure of the generated macros and tests follows
the style of #2896.

codec.txt contains comments if not all encodings of an instruction are
supported yet. Also missing are the Arm v8.3-a FCADD and FCMLA
instructions, because their rotation arguments require a bit of special
handling to get nice macros.

Issue #2626

Change-Id: I8c3a8ac3e03d9b466c1872ed5382639b746092b2
fhahn added a commit that referenced this issue Apr 25, 2018
)

This patch adds encoding & decoding support for most arithmetic FP Neon
instructions. The structure of the generated macros and tests follows
the style of #2896.

codec.txt contains comments if not all encodings of an instruction are
supported yet. Also missing are the Arm v8.3-a FCADD and FCMLA
instructions, because their rotation arguments require a bit of special
handling to get nice macros.

Issue #2626
fhahn added a commit that referenced this issue May 15, 2018
This commit adds encoder/decoder support for fmov from GPRs to FPRs.

It does not add support for the variant to move a 64 bit GPR to the top
of a 128 bit register (FMOV <Vd>.D[1], <Xn>). I think for that variant,
we would need a way to express the top half of a 128 bit register.

Issue #2626

Change-Id: I9105b5ce5cc38a6b6cd33c8390a8822b091a44cf
fhahn added a commit that referenced this issue May 16, 2018
This commit adds encoder/decoder support for fmov from GPRs to FPRs.

Issue #2626
fhahn added a commit that referenced this issue May 16, 2018
This patch implements instr_is_encoding_possible and encoding_possible
using encode_common, which returns ENCFAIL in case of a failure. This
is not the most efficient implementation, but we do not have encoding
tables available in the AArch64 backend.

As a test case, it includes a check to make sure the encoder rejects
some invalid combinations of FMOV.

Issue #2626

Change-Id: I5a8e32c032649ac39c01ca0a7f46b29b043d5136
fhahn added a commit that referenced this issue May 16, 2018
This patch implements instr_is_encoding_possible and encoding_possible
using encode_common, which returns ENCFAIL in case of a failure. This
is not the most efficient implementation, but we do not have encoding
tables available in the AArch64 backend.

As a test case, it includes a check to make sure the encoder rejects
some invalid combinations of FMOV.

Issue #2626

Change-Id: I5a8e32c032649ac39c01ca0a7f46b29b043d5136
fhahn added a commit that referenced this issue May 17, 2018
Some instructions, like FMLA/FMLS also read the destination register.
I think in the IR, we should have them as source registers too.

I kept the INSTR_CREATE_ macros to not have a extra source operand, as
this is closer to the AArch64 assembly syntax.

Issue: #2626
Change-Id: Ib5c874e6ee6a542b5fdb5f6927b9a878bcd1c602
fhahn added a commit that referenced this issue May 18, 2018
Some instructions, like FMLA/FMLS also read the destination register.
I think in the IR, we should have them as source registers too.

I kept the INSTR_CREATE_ macros to not have a extra source operand, as
this is closer to the AArch64 assembly syntax.

Issue: #2626
fhahn added a commit that referenced this issue May 18, 2018
This patch implements instr_is_encoding_possible and encoding_possible
using encode_common, which returns ENCFAIL in case of a failure. This
is not the most efficient implementation, but we do not have encoding
tables available in the AArch64 backend.

As a test case, it includes a check to make sure the encoder rejects
some invalid combinations of FMOV.

Issue #2626
fhahn added a commit that referenced this issue May 18, 2018
This patch adds a set of Python scripts to generate
 * codec.txt patterns
 * instr_create.h macros
 * tests (dis-a64.txt, ir_aarch64.c, ir_aarch64.expect)

from the public Armv8-a XML ISA spec from [1]. Currently it only
supports a subset of floating point SIMD and scalar instructions.

Issues #2626

[1] https://developer.arm.com/products/architecture/a-profile/exploration-tools

Change-Id: I5afe704e099671a92d7a0db2914cee02258267b2
fhahn added a commit that referenced this issue May 21, 2018
This patch adds an isz operand to encode the vector element width for
non-FP vector instructions. It also adds support for vector ADD to the
encoder/decoder. Additional tests and macros should be added once the
script in the project-aarch64-generate-patterns branch gets updated.

Issue #2626

Change-Id: I2bca21610205c3b2ba7bb67f990fe108d210001c
fhahn added a commit that referenced this issue May 22, 2018
Currently both the fsz16 and fsz operands were looking at bits 21 and
22, while they only need to look at bit 22. This fix allows us to use
fsz/fsz16 for other encoding classes, like the ones used for indexed FP
instructions.

It also moves the operands to their right position.

Issue #2626

Change-Id: Ib9147b756a6851ff31b1d190307fdeb904c72f41
@fhahn
Copy link
Contributor

fhahn commented May 22, 2018

I pushed a first version of the script I used to generate everything for #2951 to the project-aarch64-generate-patterns branch. For completing support for NEON, we should extend those scripts to generate everything for the missing instructions.

AssadHashmi pushed a commit that referenced this issue Apr 22, 2024
This patch adds the appropriate macros, tests and codec entries to
encode the following variants:
```
FRINT32X <Vd>.2S, <Vn>.2S
FRINT32X <Vd>.4S, <Vn>.4S
FRINT32X <Vd>.2D, <Vn>.2D
FRINT32X <Dd>, <Dn>
FRINT32X <Sd>, <Sn>
FRINT32Z <Vd>.2S, <Vn>.2S
FRINT32Z <Vd>.4S, <Vn>.4S
FRINT32Z <Vd>.2D, <Vn>.2D
FRINT32Z <Dd>, <Dn>
FRINT32Z <Sd>, <Sn>
FRINT64X <Vd>.2S, <Vn>.2S
FRINT64X <Vd>.4S, <Vn>.4S
FRINT64X <Vd>.2D, <Vn>.2D
FRINT64X <Dd>, <Dn>
FRINT64X <Sd>, <Sn>
FRINT64Z <Vd>.2S, <Vn>.2S
FRINT64Z <Vd>.4S, <Vn>.4S
FRINT64Z <Vd>.2D, <Vn>.2D
FRINT64Z <Dd>, <Dn>
FRINT64Z <Sd>, <Sn>
```
Issue: #2626
jackgallagher-arm added a commit that referenced this issue May 20, 2024
This patch adds the appropriate macros, tests and codec entries to
decode and encode the following instructions:
```
LDGM    <Xt>, [<Xn|SP>]
STGM    <Xt>, [<Xn|SP>]
STZGM   <Xt>, [<Xn|SP>]
```

Issue: #2626
jackgallagher-arm added a commit that referenced this issue May 20, 2024
The AArch64 codec is split by v8.x architecture version but the features
grouped into the v8.6 files were actually from earlier architecture
versions.

BF16 -> v8.2
I8MM -> v8.2
MTE  -> v8.5
MTE2 -> v8.5

This commit just moves the 4 features into the correct files. This should
just be a cosmetic change.

Issue: #2626
jackgallagher-arm added a commit that referenced this issue May 20, 2024
Adds a set of macros that new AArch64 ir tests can use to make extra
assert-style checks on the instructions being tested, and ports the MTE
ld*g/st*g instruction tests to use it.

Issue: #2626
jackgallagher-arm added a commit that referenced this issue May 20, 2024
This patch adds the appropriate macros, tests and codec entries to
decode and encode the following instructions:
```
LDGM    <Xt>, [<Xn|SP>]
STGM    <Xt>, [<Xn|SP>]
STZGM   <Xt>, [<Xn|SP>]
```

As part of adding support for these instructions I spotted that the
existing FEAT_MTE instructions were in the wrong architecture version
files, and in fact all the instructions in the v8.6 files didn't
belong there, so I moved them all to the correct files based on the
architecture version of the features:

BF16 -> v8.2
I8MM -> v8.2
MTE  -> v8.5
MTE2 -> v8.5

Issue: #2626
jackgallagher-arm added a commit that referenced this issue May 21, 2024
This patch adds the appropriate macros, tests and codec entries
to encode the following variants:
```
AXFLAG
XAFLAG
```

Issue: #2626
jackgallagher-arm added a commit that referenced this issue May 21, 2024
This patch adds the appropriate macros, tests and codec entries to
encode the following variants:
```
AXFLAG
XAFLAG
```

Issue: #2626
philramsey-arm added a commit that referenced this issue Jun 3, 2024
Registers like ID_AA64ISAR0_EL1 are readable at EL0 on Linux, but are
not included in the DR_REG enum as this only includes EL0 registers.

This means that MRS instructions that read these registers will not
be disassembled in the normal way in the DR log.

Issue: #2626
philramsey-arm added a commit that referenced this issue Jun 4, 2024
Registers like ID_AA64ISAR0_EL1 are readable at EL0 on Linux, but are
not included in the DR_REG enum as this only includes EL0 registers.

This means that MRS instructions that read these registers will not be
disassembled in the normal way in the DR log.

Issue: #2626
jackgallagher-arm added a commit that referenced this issue Jun 5, 2024
The instructions

MRS <Xt>, RNDR
MRS <Xt>, RNDRRS

read a random number into the register Xt and set the value of NZCV to
indicate whether the instruction was able to return a genuine random
number.

Previously the codec did not set the correct eflags value to indicate
that this instruction writes to NZCV.

Also previously there wasn't an IR test for the MRS instructions so I
have added one and included a check for the eflags value in the test.

All the existing v8.0 IR tests in ir_aarch64.c which predates the
TEST_LOOP* macros that we now use for instruction tests, and
ir_aarch64.c has its slightly different own version of the
test_instr_encoding() function so I couldn't include ir_aarch64.h in
ir_aarch64.c without updating the >1000 tests already there which use
it. Instead I created a new file ir_aarch64_v80.c so that new v8.0
instruction tests can be created using the TEST_LOOP* macros without
interfering with existing tests.

Issue: #2626
jackgallagher-arm added a commit that referenced this issue Jun 6, 2024
)

The instructions

MRS <Xt>, RNDR
MRS <Xt>, RNDRRS

read a random number into the register Xt and set the value of NZCV to
indicate whether the instruction was able to return a genuine random
number.

Previously the codec did not set the correct eflags value to indicate
that this instruction writes to NZCV.

Also previously there wasn't an IR test for the MRS instructions so I
have added one and included a check for the eflags value in the test.

All the existing v8.0 IR tests in ir_aarch64.c which predates the
TEST_LOOP* macros that we now use for instruction tests, and
ir_aarch64.c has its slightly different own version of the
test_instr_encoding() function so I couldn't include ir_aarch64.h in
ir_aarch64.c without updating the >1000 tests already there which use
it. Instead I created a new file ir_aarch64_v80.c so that new v8.0
instruction tests can be created using the TEST_LOOP* macros without
interfering with existing tests.

Issue: #2626
jackgallagher-arm added a commit that referenced this issue Jun 6, 2024
Extends INSTR_CREATE_msr to be able to encode the immediate variant of
the MSR instruction:
    MSR <pstatefield>, #<imm>

Adds codec support for some missing pstatefields, and adds missing IR and
disassembly tests for MSR.

Issue: #2626
jackgallagher-arm added a commit that referenced this issue Jun 10, 2024
Extends INSTR_CREATE_msr to be able to encode the immediate variant of
the MSR instruction:
```
    MSR <pstatefield>, #<imm>
```

Adds codec support for some missing pstatefields, and adds missing IR
and disassembly tests for MSR.

Issue: #2626
philramsey-arm added a commit that referenced this issue Jun 10, 2024
Add encoding for the WFIT and WFET instructions. Also add
identification of FEAT_WFxT as FEATURE_WFxT.

Issue: #2626
philramsey-arm added a commit that referenced this issue Jun 11, 2024
Add encoding for the WFIT and WFET instructions. Also add identification
of FEAT_WFxT as FEATURE_WFxT.

Issue: #2626
jackgallagher-arm added a commit that referenced this issue Jun 12, 2024
While working on another patch I noticed we were missing macros to create
the GPR ORR instructions so this patch adds them along with IR unit tests.

Issue: #2626
jackgallagher-arm added a commit that referenced this issue Jun 25, 2024
While working on another patch I noticed we were missing macros to
create the GPR ORR instructions so this patch adds them along with IR
unit tests.

Issue: #2626
joshua-warburton added a commit that referenced this issue Aug 14, 2024
Previously we selected the default python interpreter to run the codec
this *usually* found python3 but on some systems would resolve
to python2 and cause the codec generator to fail. This
change enforces python3 as a requirement

issue: #2626

Change-Id: I4d1a2ac433b522d69e97960d574d925debd54bb2
joshua-warburton added a commit that referenced this issue Aug 15, 2024
Previously we selected the default python interpreter to run the codec
this *usually* found python3 but on some systems would resolve to
python2 and cause the codec generator to fail. This change enforces
python3 as a requirement

issue: #2626
philramsey-arm added a commit that referenced this issue Dec 13, 2024
Python 3.12 is strict about escape characters - '\^' is not a
valid escape sequence.

Add the 'r' prefix to strings containing '\^' so they are treated as
raw strings.

Issue: #2626
philramsey-arm added a commit that referenced this issue Dec 16, 2024
….12 (#7130)

Python 3.12 is strict about escape characters - '\\^' is not a valid
escape sequence.

Add the 'r' prefix to strings containing '\\^' so they are treated as
raw strings.

Issue: #2626
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants