public inbox for binutils@sourceware.org
 help / color / mirror / Atom feed
From: Jan Beulich <jbeulich@suse.com>
To: Binutils <binutils@sourceware.org>
Cc: "H.J. Lu" <hjl.tools@gmail.com>,
	"Jiang, Haochen" <haochen.jiang@intel.com>
Subject: Re: [PATCH v2 00/14] x86: new .insn directive
Date: Fri, 24 Mar 2023 10:51:25 +0100	[thread overview]
Message-ID: <ce0e023b-af7a-8fe8-3638-e0b89ade5fb1@suse.com> (raw)
In-Reply-To: <b3625235-faf6-00ad-69c2-82583531fe43@suse.com>

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

      parent reply	other threads:[~2023-03-24  9:51 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-03-10 10:17 Jan Beulich
2023-03-10 10:19 ` [PATCH v2 01/14] x86: introduce " Jan Beulich
2023-03-10 10:19 ` [PATCH v2 02/14] x86: parse VEX and alike specifiers for .insn Jan Beulich
2023-03-10 10:20 ` [PATCH v2 03/14] x86: parse special opcode modifiers " Jan Beulich
2023-03-10 10:21 ` [PATCH v2 04/14] x86: re-work build_modrm_byte()'s register assignment Jan Beulich
2023-03-10 10:21 ` [PATCH v2 05/14] x86: VexVVVV is now merely a boolean Jan Beulich
2023-03-10 10:22 ` [PATCH v2 06/14] x86: drop "shimm" special case template expansions Jan Beulich
2023-03-10 10:22 ` [PATCH v2 07/14] x86/AT&T: restrict recognition of the "absolute branch" prefix character Jan Beulich
2023-03-10 10:23 ` [PATCH v2 08/14] x86: process instruction operands for .insn Jan Beulich
2023-03-10 10:24 ` [PATCH v2 09/14] x86: handle EVEX Disp8 " Jan Beulich
2023-03-10 10:24 ` [PATCH v2 10/14] x86: allow for multiple immediates in output_disp() Jan Beulich
2023-03-10 10:25 ` [PATCH v2 11/14] x86: handle immediate operands for .insn Jan Beulich
2023-03-10 10:26 ` [PATCH v2 12/14] x86: document .insn Jan Beulich
2023-03-10 10:26 ` [PATCH v2 13/14] x86: convert testcases to use .insn Jan Beulich
2023-04-20  8:56   ` Clément Chigot
2023-04-20  9:01     ` Jan Beulich
2023-04-20  9:09       ` Clément Chigot
2023-04-20  9:19         ` Jan Beulich
2023-04-20  9:22           ` Clément Chigot
2023-03-10 10:27 ` [PATCH RFC v2 14/14] x86: .insn example - VEX-encoded instructions of original Xeon Phi Jan Beulich
2023-03-24  9:51 ` Jan Beulich [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=ce0e023b-af7a-8fe8-3638-e0b89ade5fb1@suse.com \
    --to=jbeulich@suse.com \
    --cc=binutils@sourceware.org \
    --cc=haochen.jiang@intel.com \
    --cc=hjl.tools@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).