DynamoRIO / DynamoRIO/dynamorio

AArch64 codec imm5 encodes width and position of vector element

Open
#6,448 2 comments 0 reactions 1 assignee Claimed by @egrimley-arm View on GitHub
OpSys-AArch64
Dominant language
C
Stars
3.2k
Forks
629
Avg merge
2d 15h
Merged PRs (30d)
31

Description

It is currently (568aef530228d197ff2fed5f13409e1511addee3) impossible to encode `5e020400 mov h0, v0.h[0]` (which is an alias of DUP): you get `4e020400 dup v0.8h, v0.h[0]` instead. Demonstrate by adding this line to `dis-a64.txt` and running `ctest -V -R dis-a64$`:
```
5e020400 : mov h0, v0.h[0] : dup %q0 $0x02 -> %q0
```

The corresponding lines in `codec_v80.txt` are:
```
01011110000xxxxx000001xxxxxxxxxx n 88 BASE dup dq0 : dq5 imm5
01001110000xxxxx000001xxxxxxxxxx n 88 BASE dup q0 : q5 imm5
```

But the `imm5` is in any case inconvenient for both instructions because it encodes both the width and the position of the element being duplicated. The lines that use `imm5` are:
```
01011110000xxxxx000001xxxxxxxxxx n 88 BASE dup dq0 : dq5 imm5
00001110000xxxxx000001xxxxxxxxxx n 88 BASE dup d0 : d5 imm5
01001110000xxxxx000001xxxxxxxxxx n 88 BASE dup q0 : q5 imm5
01101110000xxxxx0xxxx1xxxxxxxxxx n 171 BASE ins q0 imm5 : q5 imm4idx
```

I think those instructions should probably use separate integer operands: one for the width, with 0 meaning `b`, 1 meaning `h`, and so on, and one for the index. Probably the width should always be a source operand, and the index should be a destination or source operand depending on whether it refers to a destination or source register. However, I wouldn't know for sure if that is feasible until I tried it.

(One could invent a new kind of operand to represent "width of vector element" but I think that would be very unhelpful in practice and it would be a big change affecting lots of instructions.)

Contributor guide

Open the contributing guide

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.