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

AArch64 decoder/encoder improvements #4393

Open
AssadHashmi opened this issue Aug 5, 2020 · 1 comment
Open

AArch64 decoder/encoder improvements #4393

AssadHashmi opened this issue Aug 5, 2020 · 1 comment

Comments

@AssadHashmi
Copy link
Contributor

AssadHashmi commented Aug 5, 2020

The current method of generating decode/encode functions based on the codec.txt bitmap format has limitations in terms of:

The proposal is to use the publicly available XML specifications to replace codec.txt as the source from which to generate decode/encode functionality. Useful links:
https://alastairreid.github.io/ARM-v8a-xml-release/
https://developer.arm.com/architectures/instruction-sets/base-isas/a64
https://github.com/alastairreid/mra_tools

@fhahn
Copy link
Contributor

fhahn commented Aug 5, 2020

There are some script to auto-generate parts of codec.txt, tests and instr_create.h macros from an ISA description on the branch: https://github.com/DynamoRIO/dynamorio/commits/project-aarch64-generate-patterns

Not sure how well they aged though.

AssadHashmi added a commit that referenced this issue Feb 8, 2022
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
AssadHashmi added a commit that referenced this issue Feb 8, 2022
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
AssadHashmi added a commit that referenced this issue Apr 8, 2022
This patch is an example of the code which will be generated from a
machine readable specification (MRS) to decode and encode AArch64
instructions from v8.1 onwards.

It is provided for review and discussion purposes, in order to resolve
any issues which may arise and to make visible what changes to expect.

This patch does not include the MRS, the parser or generator, just an
example of the target code which we intend to generate, based on the
v8.1 SQRDMLAH instruction.

Issue: #4393, #3044, #2626
AssadHashmi added a commit that referenced this issue Apr 27, 2022
This patch is an example of the code which will be generated from a
machine readable specification (MRS) to decode and encode AArch64
instructions from v8.1 onwards.

It is provided for review and discussion purposes, in order to resolve
any issues which may arise and to make visible what changes to expect.

This patch does not include the MRS, the parser or generator, just an
example of the target code which we intend to generate, based on the
v8.1 SQRDMLAH instruction.

Issue: #4393, #3044, #2626
AssadHashmi added a commit that referenced this issue Jul 1, 2022
- Removes the code put in place by PR5453 in preparation for a new
  codec.
- Moves v8.1 instruction definitions from codec_v80.txt to
  codec_v81.txt.
- Fixes bug in SQRDMLAH.

Issue: #4393, #2626
dolanzhao pushed a commit that referenced this issue Jul 1, 2022
- Removes the code put in place by PR5453 in preparation for a new
  codec.
- Moves v8.1 instruction definitions from codec_v80.txt to
  codec_v81.txt.
- Fixes bug in SQRDMLAH.

Issue: #4393, #2626
joshua-warburton added a commit that referenced this issue Nov 23, 2022
This patch modifies the testing macros to reduce the need to
instantiate variables in each test.

It also predefines some lists of registers that are commonly
used

issues: #4393

Change-Id: I33be226fdb73b9c178c2ba1d7047bd8db047dbdd
joshua-warburton added a commit that referenced this issue Nov 24, 2022
This patch modifies the testing macros to reduce the need to
instantiate variables in each test.

It also predefines some lists of registers that are commonly
used

issues: #4393
jackgallagher-arm added a commit that referenced this issue Jan 13, 2023
This pulls out code for encoding and decoding 8-bit floating-point
immedate values into helper functions that can be re-used for future
instructions with similar operands.

Issues: #4393, #2626
jackgallagher-arm added a commit that referenced this issue Jan 13, 2023
Many immediate value operands follow the naming convention:
 <type>imm<size>_<lsb>

So you would expect fpimm13 to be a 13-bit floating-point immediate value.
It is actually an 8-bit floating-point immediate value at bit 13 so
following the above naming convention it should be called fpimm8_13.

Issues: #4393
jackgallagher-arm added a commit that referenced this issue Jan 16, 2023
This pulls out code for encoding and decoding 8-bit floating-point
immediate values into helper functions that can be re-used for future
instructions with similar operands.

This commit also renames the fpimm13 operand to fpimm8_13

Many immediate value operands follow the naming convention:
 <type>imm<size>[_<lsb>]

So you would expect fpimm13 to be a 13-bit floating-point immediate value.
It is actually an 8-bit floating-point immediate value at bit 13 so
following the above naming convention it should be called fpimm8_13.

Issues: #4393
dolanzhao pushed a commit that referenced this issue Jan 30, 2023
This pulls out code for encoding and decoding 8-bit floating-point
immediate values into helper functions that can be re-used for future
instructions with similar operands.

This commit also renames the fpimm13 operand to fpimm8_13

Many immediate value operands follow the naming convention:
 <type>imm<size>[_<lsb>]

So you would expect fpimm13 to be a 13-bit floating-point immediate value.
It is actually an 8-bit floating-point immediate value at bit 13 so
following the above naming convention it should be called fpimm8_13.

Issues: #4393
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

3 participants