mbox series

[v2,00/14] x86: new .insn directive

Message ID b3625235-faf6-00ad-69c2-82583531fe43@suse.com
Headers
Series x86: new .insn directive |

Message

Jan Beulich March 10, 2023, 10:17 a.m. UTC 
  Especially when instructions which are not known to gas yet also take
register or, yet worse, memory operands, encoding such in code actually
wanting to make use of them is often difficult. Typically people resort
to hard-coding the involved registers, thus being able to express
things via .byte. To overcome this limitation (to a sufficient degree
at least), introduce .insn. This allows users to specify operands in
their "normal" shape (possibly in slightly altered order). Peculiarities
require two small syntax extensions; see the implementation or
documentation for details.

In order to re-use sufficiently much of the functionality md_assemble()
already uses, some adjustments to existing code were necessary. The one
item to call out here is the partial re-write of build_modrm_byte()
(patch 7), which actually turned out to simplify things. Subsequently
possible further tidying is carried out right away (patches 8 and 9),
even if not strictly related to the .insn work.

I'm pretty sure there are still corner cases which aren't taken care of
correctly. It's also quite possible that I've overlooked further places
in pre-existing code which need tweaking for .insn. People taking a
close look and/or playing with the new functionality would be much
appreciated.

The last patch in the series continues to be RFC, as I'm uncertain
whether we actually want this kind of a testcase.

Main changes in v2 are testsuite adjustments for certain non-Linux
targets, resulting from me not properly having re-run wider tests with
the last few patches in the series in place.

01: introduce .insn directive
02: parse VEX and alike specifiers for .insn
03: parse special opcode modifiers for .insn
04: re-work build_modrm_byte()'s register assignment
05: VexVVVV is now merely a boolean
06: drop "shimm" special case template expansions
07: AT&T: restrict recognition of the "absolute branch" prefix character
08: process instruction operands for .insn
09: handle EVEX Disp8 for .insn
10: allow for multiple immediates in output_disp()
11: handle immediate operands for .insn
12: document .insn
13: convert testcases to use .insn
14: .insn example - VEX-encoded instructions of original Xeon Phi

Jan

Comments

Jan Beulich March 24, 2023, 9:51 a.m. UTC | #1 
On 10.03.2023 11:17, Jan Beulich via Binutils wrote:
> Especially when instructions which are not known to gas yet also take
> register or, yet worse, memory operands, encoding such in code actually
> wanting to make use of them is often difficult. Typically people resort
> to hard-coding the involved registers, thus being able to express
> things via .byte. To overcome this limitation (to a sufficient degree
> at least), introduce .insn. This allows users to specify operands in
> their "normal" shape (possibly in slightly altered order). Peculiarities
> require two small syntax extensions; see the implementation or
> documentation for details.
> 
> In order to re-use sufficiently much of the functionality md_assemble()
> already uses, some adjustments to existing code were necessary. The one
> item to call out here is the partial re-write of build_modrm_byte()
> (patch 7), which actually turned out to simplify things. Subsequently
> possible further tidying is carried out right away (patches 8 and 9),
> even if not strictly related to the .insn work.
> 
> I'm pretty sure there are still corner cases which aren't taken care of
> correctly. It's also quite possible that I've overlooked further places
> in pre-existing code which need tweaking for .insn. People taking a
> close look and/or playing with the new functionality would be much
> appreciated.
> 
> The last patch in the series continues to be RFC, as I'm uncertain
> whether we actually want this kind of a testcase.
> 
> Main changes in v2 are testsuite adjustments for certain non-Linux
> targets, resulting from me not properly having re-run wider tests with
> the last few patches in the series in place.
> 
> 01: introduce .insn directive
> 02: parse VEX and alike specifiers for .insn
> 03: parse special opcode modifiers for .insn
> 04: re-work build_modrm_byte()'s register assignment
> 05: VexVVVV is now merely a boolean
> 06: drop "shimm" special case template expansions
> 07: AT&T: restrict recognition of the "absolute branch" prefix character
> 08: process instruction operands for .insn
> 09: handle EVEX Disp8 for .insn
> 10: allow for multiple immediates in output_disp()
> 11: handle immediate operands for .insn
> 12: document .insn
> 13: convert testcases to use .insn
> 14: .insn example - VEX-encoded instructions of original Xeon Phi

Unless I hear back otherwise with some good reasons not to, I intend to
commit the remaining patches (with one further !BFD64 build fix) some time
next week. Would certainly be nice to have an explicit view voiced by
somebody on whether to include the last patch ...

Jan