public inbox for binutils@sourceware.org
 help / color / mirror / Atom feed
From: "H.J. Lu" <hjl.tools@gmail.com>
To: Jan Beulich <jbeulich@suse.com>
Cc: binutils@sourceware.org
Subject: Re: [PATCH] x86: Allow 16-bit register source for LAR and LSL
Date: Tue, 6 Dec 2022 08:11:11 -0800	[thread overview]
Message-ID: <CAMe9rOrtUD-hc1AZFyCTUJavmPhDtaQbKppPn6HqXBH-krijVQ@mail.gmail.com> (raw)
In-Reply-To: <3977276e-762c-661e-6b0d-f757debb5ae0@suse.com>

On Mon, Dec 5, 2022 at 11:51 PM Jan Beulich <jbeulich@suse.com> wrote:
>
> On 06.12.2022 00:20, H.J. Lu wrote:
> > On Mon, Dec 5, 2022 at 3:11 AM Jan Beulich <jbeulich@suse.com> wrote:
> >>
> >> On 03.12.2022 05:13, H.J. Lu wrote:
> >>> Since LAR and LSL only access 16 bits of the source operand, regardless
> >>> of operand size, allow 16-bit register source for LAR and LSL, and always
> >>> disassemble LAR and LSL with 16-bit source operand.
> >>>
> >>> gas/
> >>>
> >>>       PR gas/29844
> >>>       * testsuite/gas/i386/i386.s: Add tests for LAR and LSL.
> >>>       * testsuite/gas/i386/x86_64.s: Likewise.
> >>>       * testsuite/gas/i386/intelbad.s: Remove "lar/lsl eax, ax".
> >>>       * testsuite/gas/i386/i386-intel.d: Updated.
> >>>       * testsuite/gas/i386/i386.d: Likewise.
> >>>       * testsuite/gas/i386/intel-intel.d: Likewise.
> >>>       * testsuite/gas/i386/intel.d: Likewise.
> >>>       * testsuite/gas/i386/intelbad.l: Likewise.
> >>>       * testsuite/gas/i386/x86_64-intel.d: Likewise.
> >>>       * testsuite/gas/i386/x86_64.d: Likewise.
> >>>
> >>> opcodes/
> >>>
> >>>       PR gas/29844
> >>>       * i386-dis.c (MOD_0F02): Removed.
> >>>       (MOD_0F03): Likewise.
> >>>       (dis386_twobyte): Restore larS and lslS.
> >>>       (mod_table): Remove MOD_0F02 and MOD_0F03.
> >>>       * i386-opc.tbl: Allow 16-bit register source for LAR and LSL.
> >>>       * i386-tbl.h: Regenerated.
> >>
> >> Please can you refrain from immediately committing patches which have
> >> a risk of being controversial.
> >>
> >> In the case here, given there are uses of the 16-bit register operand
> >> form in the Linux kernel, I can accept the assembler part of the change.
> >> The lines in i386-opc.tbl, however, need a comment then, as allowing for
> >> 16-bit registers despite a wider destination is explicitly not in line
> >> with the SDM. (Interestingly AMD's PM is different in this regard.)
> >>
> >> For the disassembler part you're completely undoing what I did, which is
> >> wrong - again with reference to the SDM. If you want to accommodate for
> >> AMD's PM, then you need to vary disassembly according to command line
> >> options specified, with the default being in line with the SDM (I can
> >> dig out a pretty old version of the doc, but I believe it has always
> >> been that way, i.e. even before AMD introduced their clones).
> >>
> >> I will revert this change unless you come forward with an adjustment
> >> within the next couple of days.
> >>
> >
> > Given that the only lower 16 bits are used, the 16-bit register source
> > is more appropriate.  I will raise the issue with the Intel SDM author.
>
> I see no point in changing the documentation when what's there has been
> valid for well over 30 years. There are other cases in newer insns where
> only the low 16 (or 8) bits are used, yet still the 32-bit register name
> is specified ({,v}pinsr{b,w} come to mind immediately). Also what you've
> done brought things out of sync with mov-to-sreg (and no, please don't
> "restore" consistency by also changing disassembly there).

The 16-bit register has been used in both assembler and disassembler
for well over 30 years.  I consider this a flaw in the spec.

> My request stand: Please undo / adjust the disassembler change you've
> done, or I'll have to revert the entire commit as being wrong and having
> been committed prematurely.
>
> Jan



-- 
H.J.

  reply	other threads:[~2022-12-06 16:11 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-12-03  4:13 H.J. Lu
2022-12-05 11:10 ` Jan Beulich
2022-12-05 23:20   ` H.J. Lu
2022-12-06  7:51     ` Jan Beulich
2022-12-06 16:11       ` H.J. Lu [this message]
2022-12-06 16:36         ` Jan Beulich
2022-12-06 22:32           ` H.J. Lu
2022-12-07 10:47             ` Jan Beulich
2022-12-07 23:57               ` H.J. Lu
2022-12-08  7:38                 ` Jan Beulich
2022-12-09  2:11                   ` H.J. Lu
2022-12-08  7:20     ` Jan Beulich

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=CAMe9rOrtUD-hc1AZFyCTUJavmPhDtaQbKppPn6HqXBH-krijVQ@mail.gmail.com \
    --to=hjl.tools@gmail.com \
    --cc=binutils@sourceware.org \
    --cc=jbeulich@suse.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).