From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-il1-x12b.google.com (mail-il1-x12b.google.com [IPv6:2607:f8b0:4864:20::12b]) by sourceware.org (Postfix) with ESMTPS id 716753857C49 for ; Tue, 4 Aug 2020 12:37:04 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 716753857C49 Received: by mail-il1-x12b.google.com with SMTP id l17so23783250ilq.13 for ; Tue, 04 Aug 2020 05:37:04 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=/5aDhlTGviP5UDRpXwDHw3Pf+W6SqSWs3fSsL+2CdcY=; b=n1Dn24JpgnTcTuANvNQpVcadRChJ+PgvqbJicHI0gA8BkR4zbTnU2vB1XoKOLe2EvV n6FoAm5geavo6PS7qXwTzD9dvwHdt+FV8Q5CsrlZ6U0XrGZPvIxqa5NDbpqjkOgk9tsi +IAg+U4lQ9UuLFVnxv5fnMXs227xof7LgIz9vsnB7h/IHqVt/5pxmj+gtm5AG82Wihlf Iv6x9xww1unhFlx0QNsN0m7PDRBlke3QDVDcJQ7Ryj0jhoM7yISn9B8GSwnrS5w46/jU ID38pqNn8JEgamwTMHKFcwuODI1yj1gt11m1hAhyitT85wcUILL1g7cKE8bwBGDrRtVF H5wA== X-Gm-Message-State: AOAM532nh4J77HGcFvfIDL+OWkC4FrNmxgGs9j52cpDxEtJGcr40Z4FU qVy5UjN4oWfDKTZJAnuvME1S3Oy59mJewBQw19g= X-Google-Smtp-Source: ABdhPJwQCzCrVIbr8wUlRK1/Csth6KiC2K44yOIcH+fDEROETkSY1xDOopvJI0v1tdPl0kkxkgMkoXCRITEhPNWqCiY= X-Received: by 2002:a05:6e02:e89:: with SMTP id t9mr4696049ilj.292.1596544623748; Tue, 04 Aug 2020 05:37:03 -0700 (PDT) MIME-Version: 1.0 References: <20200727232348.651237-1-hjl.tools@gmail.com> In-Reply-To: From: "H.J. Lu" Date: Tue, 4 Aug 2020 05:36:27 -0700 Message-ID: Subject: Re: V2 [PATCH] x86: Add {disp16} pseudo prefix To: Jan Beulich , Nick Clifton Cc: Binutils Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-5.1 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, FREEMAIL_FROM, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org X-BeenThere: binutils@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Binutils mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Aug 2020 12:37:05 -0000 On Wed, Jul 29, 2020 at 4:39 PM H.J. Lu wrote: > > On Wed, Jul 29, 2020 at 3:53 PM H.J. Lu wrote: > > > > On Wed, Jul 29, 2020 at 1:26 PM Jan Beulich wrote: > > > > > > On 28.07.2020 22:30, H.J. Lu wrote: > > > > On Tue, Jul 28, 2020 at 12:02 PM H.J. Lu wrote: > > > >> > > > >> On Tue, Jul 28, 2020 at 11:43 AM Jan Beulich wrote: > > > >>> > > > >>> On 28.07.2020 01:23, H.J. Lu via Binutils wrote: > > > >>>> Since (%bp)/(%ebp)/(%rbp) are encoded as 0(%bp)/0(%ebp)/0(%rbp), use > > > >>>> disp32/disp16 on 0(%bp)/0(%ebp)/0(%rbp) for {disp32}. > > > >>> > > > >>> Same for (%r13d) / (%r13) afaict? > > > >> > > > >> Yes. {disp32} works on (%r13d) / (%r13) now: > > > >> > > > >> [hjl@gnu-cfl-2 testsuite]$ cat x.s > > > >> movb (%r13),%al > > > >> {disp8} movb (%r13),%al > > > >> {disp32} movb (%r13),%al > > > >> > > > >> movb (%r13d),%al > > > >> {disp8} movb (%r13d),%al > > > >> {disp32} movb (%r13d),%al > > > >> [hjl@gnu-cfl-2 testsuite]$ gcc -c x.s > > > >> [hjl@gnu-cfl-2 testsuite]$ objdump -dw x.o > > > >> > > > >> x.o: file format elf64-x86-64 > > > >> > > > >> > > > >> Disassembly of section .text: > > > >> > > > >> 0000000000000000 <.text>: > > > >> 0: 41 8a 45 00 mov 0x0(%r13),%al > > > >> 4: 41 8a 45 00 mov 0x0(%r13),%al > > > >> 8: 41 8a 45 00 mov 0x0(%r13),%al > > > >> c: 67 41 8a 45 00 mov 0x0(%r13d),%al > > > >> 11: 67 41 8a 45 00 mov 0x0(%r13d),%al > > > >> 16: 67 41 8a 45 00 mov 0x0(%r13d),%al > > > >> [hjl@gnu-cfl-2 testsuite]$ ../as-new -o x.o x.s > > > >> [hjl@gnu-cfl-2 testsuite]$ objdump -dw x.o > > > >> > > > >> x.o: file format elf64-x86-64 > > > >> > > > >> > > > >> Disassembly of section .text: > > > >> > > > >> 0000000000000000 <.text>: > > > >> 0: 41 8a 45 00 mov 0x0(%r13),%al > > > >> 4: 41 8a 45 00 mov 0x0(%r13),%al > > > >> 8: 41 8a 85 00 00 00 00 mov 0x0(%r13),%al > > > >> f: 67 41 8a 45 00 mov 0x0(%r13d),%al > > > >> 14: 67 41 8a 45 00 mov 0x0(%r13d),%al > > > >> 19: 67 41 8a 85 00 00 00 00 mov 0x0(%r13d),%al > > > >> [hjl@gnu-cfl-2 testsuite]$ > > > >> > > > >> > > > >>>> Note: Since there is no disp32 on 0(%bp), use disp16 instead. > > > >>> > > > >>> What use is it to fix the special case of (%bp) when the more general > > > >>> case ((%bx), (%si), etc) doesn't work? I anyway think that instead of > > > >>> ... > > > >>> > > > >>>> --- a/gas/config/tc-i386.c > > > >>>> +++ b/gas/config/tc-i386.c > > > >>>> @@ -8151,7 +8151,12 @@ build_modrm_byte (void) > > > >>>> if (operand_type_check (i.types[op], disp) == 0) > > > >>>> { > > > >>>> /* fake (%bp) into 0(%bp) */ > > > >>>> - i.types[op].bitfield.disp8 = 1; > > > >>>> + if (i.disp_encoding == disp_encoding_32bit) > > > >>>> + /* NB: Use disp16 since there is no disp32 > > > >>>> + in 16-bit mode. */ > > > >>>> + i.types[op].bitfield.disp16 = 1; > > > >>>> + else > > > >>>> + i.types[op].bitfield.disp8 = 1; > > > >>>> fake_zero_displacement = 1; > > > >>>> } > > > >>> > > > >>> ... the comment you add here, support for {disp16} should be added. > > > >>> > > > >> > > > >> I will add {disp16} to master branch. > > > >> > > > > > > > > Add {disp16} pseudo prefix and replace {disp32} pseudo prefix with > > > > {disp16} in 16-bit mode test. Check invalid {disp16}/{disp32} pseudo > > > > prefixes. > > > > > > The inval-pseudo test is a 32-bit one; you shouldn't use .code64 there, > > > or you'll cause FAILs on 32-bit only builds. > > > > I will fix it. > > > > > > Note: {disp16} can be also used on branches in 32-bit mode. > > > > > > But you don't add any tests to this effect, so it's hard to see what > > > exactly this means. To be honest I'm not sure this is helpful: A means > > > to widen the default displacement may be useful, but one to narrow not > > > just the displacement, but also the resulting new IP? > > > > {disp16} can be used to generate "branch rel16". But implementation > > may be non-trivial. > > > > > I was also wanting to ask that you group the new pseudo prefix with > > > its sibling ones in the opcode table, but I realize the use of > > > hard coded numbers makes this cumbersome. Time to do away with that? > > > > I will take a look. > > > > > I also have a tangential question: Shouldn't e.g. > > > > > > {disp8} vmovaps %xmm0,128(%eax) > > > > > > be taken as a request to use EVEX encoding, to satisfy the pseudo > > > prefix? Unless {vex} was also specified, at which point things > > > become "interesting" (but the way they're documented I think > > > {vex} has to have more wight here). > > > > > > > {disp8} is a hint for VEX. It shouldn't change to EVEX. > > > > Here is the updated patch. > > -- > H.J. I am backporting it to 2.35 branch. -- H.J.