[PATCH] x86: Handle {disp32} for (%bp)/(%ebp)/(%rbp)

classic Classic list List threaded Threaded
15 messages Options
Reply | Threaded
Open this post in threaded view
|

[PATCH] x86: Handle {disp32} for (%bp)/(%ebp)/(%rbp)

Sourceware - binutils list mailing list
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}.

Note: Since there is no disp32 on 0(%bp), use disp16 instead.

        PR gas/26305
        * config/tc-i386.c (build_modrm_byte): Use disp32/disp16 on
        (%bp)/(%ebp)/(%rbp) for {disp32}.
        * testsuite/gas/i386/pseudos.s: Add (%bp)/(%ebp) tests.
        * testsuite/gas/i386/x86-64-pseudos.s: Add (%ebp)/(%rbp) tests.
        * testsuite/gas/i386/pseudos.d: Updated.
        * testsuite/gas/i386/x86-64-pseudos.d: Likewise.
---
 gas/config/tc-i386.c                    | 12 ++++++++++--
 gas/testsuite/gas/i386/pseudos.d        | 18 ++++++++++++++++++
 gas/testsuite/gas/i386/pseudos.s        | 24 ++++++++++++++++++++++++
 gas/testsuite/gas/i386/x86-64-pseudos.d | 12 ++++++++++++
 gas/testsuite/gas/i386/x86-64-pseudos.s | 16 ++++++++++++++++
 5 files changed, 80 insertions(+), 2 deletions(-)

diff --git a/gas/config/tc-i386.c b/gas/config/tc-i386.c
index 9ab841383c..11d0e992f9 100644
--- 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;
  }
     }
@@ -8196,7 +8201,10 @@ build_modrm_byte (void)
       if (i.base_reg->reg_num == 5 && i.disp_operands == 0)
  {
   fake_zero_displacement = 1;
-  i.types[op].bitfield.disp8 = 1;
+  if (i.disp_encoding == disp_encoding_32bit)
+    i.types[op].bitfield.disp32 = 1;
+  else
+    i.types[op].bitfield.disp8 = 1;
  }
       i.sib.scale = i.log2_scale_factor;
       if (i.index_reg == 0)
diff --git a/gas/testsuite/gas/i386/pseudos.d b/gas/testsuite/gas/i386/pseudos.d
index 00c10a520b..76aae367b4 100644
--- a/gas/testsuite/gas/i386/pseudos.d
+++ b/gas/testsuite/gas/i386/pseudos.d
@@ -288,6 +288,15 @@ Disassembly of section .text:
  +[a-f0-9]+: 0f 28 90 80 00 00 00 movaps 0x80\(%eax\),%xmm2
  +[a-f0-9]+: 0f 28 90 80 00 00 00 movaps 0x80\(%eax\),%xmm2
  +[a-f0-9]+: 0f 28 90 80 00 00 00 movaps 0x80\(%eax\),%xmm2
+ +[a-f0-9]+: 8a 45 00             mov    0x0\(%ebp\),%al
+ +[a-f0-9]+: 8a 45 00             mov    0x0\(%ebp\),%al
+ +[a-f0-9]+: 8a 85 00 00 00 00     mov    0x0\(%ebp\),%al
+ +[a-f0-9]+: 67 8a 07             mov    \(%bx\),%al
+ +[a-f0-9]+: 67 8a 07             mov    \(%bx\),%al
+ +[a-f0-9]+: 67 8a 07             mov    \(%bx\),%al
+ +[a-f0-9]+: 67 8a 46 00           mov    0x0\(%bp\),%al
+ +[a-f0-9]+: 67 8a 46 00           mov    0x0\(%bp\),%al
+ +[a-f0-9]+: 67 8a 86 00 00       mov    0x0\(%bp\),%al
  +[a-f0-9]+: c4 e1 78 28 d7       vmovaps %xmm7,%xmm2
  +[a-f0-9]+: c4 e1 78 28 d7       vmovaps %xmm7,%xmm2
  +[a-f0-9]+: c4 e1 78 29 fa       vmovaps %xmm7,%xmm2
@@ -316,4 +325,13 @@ Disassembly of section .text:
  +[a-f0-9]+: 0f 28 90 80 00 00 00 movaps 0x80\(%eax\),%xmm2
  +[a-f0-9]+: 0f 28 90 80 00 00 00 movaps 0x80\(%eax\),%xmm2
  +[a-f0-9]+: 0f 28 90 80 00 00 00 movaps 0x80\(%eax\),%xmm2
+ +[a-f0-9]+: 8a 45 00             mov    0x0\(%ebp\),%al
+ +[a-f0-9]+: 8a 45 00             mov    0x0\(%ebp\),%al
+ +[a-f0-9]+: 8a 85 00 00 00 00     mov    0x0\(%ebp\),%al
+ +[a-f0-9]+: 67 8a 07             mov    \(%bx\),%al
+ +[a-f0-9]+: 67 8a 07             mov    \(%bx\),%al
+ +[a-f0-9]+: 67 8a 07             mov    \(%bx\),%al
+ +[a-f0-9]+: 67 8a 46 00           mov    0x0\(%bp\),%al
+ +[a-f0-9]+: 67 8a 46 00           mov    0x0\(%bp\),%al
+ +[a-f0-9]+: 67 8a 86 00 00       mov    0x0\(%bp\),%al
 #pass
diff --git a/gas/testsuite/gas/i386/pseudos.s b/gas/testsuite/gas/i386/pseudos.s
index 19900dd7e5..bc18654ced 100644
--- a/gas/testsuite/gas/i386/pseudos.s
+++ b/gas/testsuite/gas/i386/pseudos.s
@@ -293,6 +293,18 @@ _start:
  {disp8} movaps 128(%eax),%xmm2
  {disp32} movaps 128(%eax),%xmm2
 
+ movb (%ebp),%al
+ {disp8} movb (%ebp),%al
+ {disp32} movb (%ebp),%al
+
+ movb (%bx),%al
+ {disp8} movb (%bx),%al
+ {disp32} movb (%bx),%al
+
+ movb (%bp),%al
+ {disp8} movb (%bp),%al
+ {disp32} movb (%bp),%al
+
  .intel_syntax noprefix
  {vex3} vmovaps xmm2,xmm7
  {vex3} {load} vmovaps xmm2,xmm7
@@ -322,3 +334,15 @@ _start:
  movaps xmm2,XMMWORD PTR [eax+128]
  {disp8} movaps xmm2,XMMWORD PTR [eax+128]
  {disp32} movaps xmm2,XMMWORD PTR [eax+128]
+
+ mov al, BYTE PTR [ebp]
+ {disp8} mov al, BYTE PTR [ebp]
+ {disp32} mov al, BYTE PTR [ebp]
+
+ mov al, BYTE PTR [bx]
+ {disp8} mov al, BYTE PTR [bx]
+ {disp32} mov al, BYTE PTR [bx]
+
+ mov al, BYTE PTR [bp]
+ {disp8} mov al, BYTE PTR [bp]
+ {disp32} mov al, BYTE PTR [bp]
diff --git a/gas/testsuite/gas/i386/x86-64-pseudos.d b/gas/testsuite/gas/i386/x86-64-pseudos.d
index d5f4e05711..0fb18a3369 100644
--- a/gas/testsuite/gas/i386/x86-64-pseudos.d
+++ b/gas/testsuite/gas/i386/x86-64-pseudos.d
@@ -315,6 +315,12 @@ Disassembly of section .text:
  +[a-f0-9]+: 41 0f 28 10           movaps \(%r8\),%xmm2
  +[a-f0-9]+: 40 0f 38 01 01       rex phaddw \(%rcx\),%mm0
  +[a-f0-9]+: 41 0f 38 01 00       phaddw \(%r8\),%mm0
+ +[a-f0-9]+: 8a 45 00             mov    0x0\(%rbp\),%al
+ +[a-f0-9]+: 8a 45 00             mov    0x0\(%rbp\),%al
+ +[a-f0-9]+: 8a 85 00 00 00 00     mov    0x0\(%rbp\),%al
+ +[a-f0-9]+: 67 8a 45 00           mov    0x0\(%ebp\),%al
+ +[a-f0-9]+: 67 8a 45 00           mov    0x0\(%ebp\),%al
+ +[a-f0-9]+: 67 8a 85 00 00 00 00 mov    0x0\(%ebp\),%al
  +[a-f0-9]+: c4 e1 78 28 d7       vmovaps %xmm7,%xmm2
  +[a-f0-9]+: c4 e1 78 28 d7       vmovaps %xmm7,%xmm2
  +[a-f0-9]+: c4 e1 78 29 fa       vmovaps %xmm7,%xmm2
@@ -353,4 +359,10 @@ Disassembly of section .text:
  +[a-f0-9]+: 41 0f 28 10           movaps \(%r8\),%xmm2
  +[a-f0-9]+: 40 0f 38 01 01       rex phaddw \(%rcx\),%mm0
  +[a-f0-9]+: 41 0f 38 01 00       phaddw \(%r8\),%mm0
+ +[a-f0-9]+: 8a 45 00             mov    0x0\(%rbp\),%al
+ +[a-f0-9]+: 8a 45 00             mov    0x0\(%rbp\),%al
+ +[a-f0-9]+: 8a 85 00 00 00 00     mov    0x0\(%rbp\),%al
+ +[a-f0-9]+: 67 8a 45 00           mov    0x0\(%ebp\),%al
+ +[a-f0-9]+: 67 8a 45 00           mov    0x0\(%ebp\),%al
+ +[a-f0-9]+: 67 8a 85 00 00 00 00 mov    0x0\(%ebp\),%al
 #pass
diff --git a/gas/testsuite/gas/i386/x86-64-pseudos.s b/gas/testsuite/gas/i386/x86-64-pseudos.s
index 1bd8818121..3b3638cf75 100644
--- a/gas/testsuite/gas/i386/x86-64-pseudos.s
+++ b/gas/testsuite/gas/i386/x86-64-pseudos.s
@@ -320,6 +320,14 @@ _start:
  {rex} phaddw (%rcx),%mm0
  {rex} phaddw (%r8),%mm0
 
+ movb (%rbp),%al
+ {disp8} movb (%rbp),%al
+ {disp32} movb (%rbp),%al
+
+ movb (%ebp),%al
+ {disp8} movb (%ebp),%al
+ {disp32} movb (%ebp),%al
+
  .intel_syntax noprefix
  {vex3} vmovaps xmm2,xmm7
  {vex3} {load} vmovaps xmm2,xmm7
@@ -359,3 +367,11 @@ _start:
  {rex} movaps xmm2,XMMWORD PTR [r8]
  {rex} phaddw mm0,QWORD PTR [rcx]
  {rex} phaddw mm0,QWORD PTR [r8]
+
+ mov al, BYTE PTR [rbp]
+ {disp8} mov al, BYTE PTR [rbp]
+ {disp32} mov al, BYTE PTR [rbp]
+
+ mov al, BYTE PTR [ebp]
+ {disp8} mov al, BYTE PTR [ebp]
+ {disp32} mov al, BYTE PTR [ebp]
--
2.26.2

Reply | Threaded
Open this post in threaded view
|

Re: [PATCH] x86: Handle {disp32} for (%bp)/(%ebp)/(%rbp)

Sourceware - binutils list mailing list
On Mon, Jul 27, 2020 at 4:23 PM H.J. Lu <[hidden email]> 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}.
>
> Note: Since there is no disp32 on 0(%bp), use disp16 instead.
>
>         PR gas/26305
>         * config/tc-i386.c (build_modrm_byte): Use disp32/disp16 on
>         (%bp)/(%ebp)/(%rbp) for {disp32}.
>         * testsuite/gas/i386/pseudos.s: Add (%bp)/(%ebp) tests.
>         * testsuite/gas/i386/x86-64-pseudos.s: Add (%ebp)/(%rbp) tests.
>         * testsuite/gas/i386/pseudos.d: Updated.
>         * testsuite/gas/i386/x86-64-pseudos.d: Likewise.
I am checking in this and will backport it to 2.35 branch.

--
H.J.

0001-x86-Handle-disp32-for-bp-ebp-rbp.patch (10K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [PATCH] x86: Handle {disp32} for (%bp)/(%ebp)/(%rbp)

Jan Beulich-2
In reply to this post by Sourceware - binutils list mailing list
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?

> 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.

Jan
Reply | Threaded
Open this post in threaded view
|

Re: [PATCH] x86: Handle {disp32} for (%bp)/(%ebp)/(%rbp)

Sourceware - binutils list mailing list
On Tue, Jul 28, 2020 at 11:43 AM Jan Beulich <[hidden email]> 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.


--
H.J.
Reply | Threaded
Open this post in threaded view
|

[PATCH] x86: Add {disp16} pseudo prefix

Sourceware - binutils list mailing list
On Tue, Jul 28, 2020 at 12:02 PM H.J. Lu <[hidden email]> wrote:

>
> On Tue, Jul 28, 2020 at 11:43 AM Jan Beulich <[hidden email]> 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.

Note: {disp16} can be also used on branches in 32-bit mode.

--
H.J.

0001-x86-Add-disp16-pseudo-prefix.patch (18K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [PATCH] x86: Add {disp16} pseudo prefix

Jan Beulich-2
On 28.07.2020 22:30, H.J. Lu wrote:

> On Tue, Jul 28, 2020 at 12:02 PM H.J. Lu <[hidden email]> wrote:
>>
>> On Tue, Jul 28, 2020 at 11:43 AM Jan Beulich <[hidden email]> 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.

> 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?

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 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).

Jan
Reply | Threaded
Open this post in threaded view
|

Re: [PATCH] x86: Add {disp16} pseudo prefix

Sourceware - binutils list mailing list
On Wed, Jul 29, 2020 at 1:26 PM Jan Beulich <[hidden email]> wrote:

>
> On 28.07.2020 22:30, H.J. Lu wrote:
> > On Tue, Jul 28, 2020 at 12:02 PM H.J. Lu <[hidden email]> wrote:
> >>
> >> On Tue, Jul 28, 2020 at 11:43 AM Jan Beulich <[hidden email]> 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.

--
H.J.
Reply | Threaded
Open this post in threaded view
|

V2 [PATCH] x86: Add {disp16} pseudo prefix

Sourceware - binutils list mailing list
On Wed, Jul 29, 2020 at 3:53 PM H.J. Lu <[hidden email]> wrote:

>
> On Wed, Jul 29, 2020 at 1:26 PM Jan Beulich <[hidden email]> wrote:
> >
> > On 28.07.2020 22:30, H.J. Lu wrote:
> > > On Tue, Jul 28, 2020 at 12:02 PM H.J. Lu <[hidden email]> wrote:
> > >>
> > >> On Tue, Jul 28, 2020 at 11:43 AM Jan Beulich <[hidden email]> 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.

0001-x86-Add-disp16-pseudo-prefix.patch (38K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [PATCH] x86: Add {disp16} pseudo prefix

Jan Beulich-2
In reply to this post by Sourceware - binutils list mailing list
On 30.07.2020 00:53, H.J. Lu wrote:

> On Wed, Jul 29, 2020 at 1:26 PM Jan Beulich <[hidden email]> wrote:
>> On 28.07.2020 22:30, H.J. Lu wrote:
>>> 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.

Oh, so you mean it could be used in principle, not that it now
can be used right with the introduction of the new pseudo
prefix? If so, I simply misunderstood your use of "can", sorry.

Jan
Reply | Threaded
Open this post in threaded view
|

Re: V2 [PATCH] x86: Add {disp16} pseudo prefix

Jan Beulich-2
In reply to this post by Sourceware - binutils list mailing list
On 30.07.2020 01:39, H.J. Lu wrote:
> Here is the updated patch.

Just one more thing: Wouldn't it make sense to mark {disp16} CpuNo64,
at least as long as it's not usable for controlling branch displacements
(which, as said, I think it shouldn't get enabled for)?

Jan
Reply | Threaded
Open this post in threaded view
|

Re: [PATCH] x86: Add {disp16} pseudo prefix

Sourceware - binutils list mailing list
In reply to this post by Jan Beulich-2
On Thu, Jul 30, 2020 at 11:22 PM Jan Beulich <[hidden email]> wrote:

>
> On 30.07.2020 00:53, H.J. Lu wrote:
> > On Wed, Jul 29, 2020 at 1:26 PM Jan Beulich <[hidden email]> wrote:
> >> On 28.07.2020 22:30, H.J. Lu wrote:
> >>> 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.
>
> Oh, so you mean it could be used in principle, not that it now
> can be used right with the introduction of the new pseudo
> prefix? If so, I simply misunderstood your use of "can", sorry.
>

Yes.

--
H.J.
Reply | Threaded
Open this post in threaded view
|

Re: V2 [PATCH] x86: Add {disp16} pseudo prefix

Sourceware - binutils list mailing list
In reply to this post by Jan Beulich-2
On Fri, Jul 31, 2020 at 12:03 AM Jan Beulich <[hidden email]> wrote:
>
> On 30.07.2020 01:39, H.J. Lu wrote:
> > Here is the updated patch.
>
> Just one more thing: Wouldn't it make sense to mark {disp16} CpuNo64,
> at least as long as it's not usable for controlling branch displacements
> (which, as said, I think it shouldn't get enabled for)?

Since {disp16} can only be used for memory reference in 16-bit mode,
CpuNo64 isn't appropriate here.

--
H.J.
Reply | Threaded
Open this post in threaded view
|

Re: V2 [PATCH] x86: Add {disp16} pseudo prefix

Jan Beulich-2
On 31.07.2020 13:52, H.J. Lu wrote:

> On Fri, Jul 31, 2020 at 12:03 AM Jan Beulich <[hidden email]> wrote:
>>
>> On 30.07.2020 01:39, H.J. Lu wrote:
>>> Here is the updated patch.
>>
>> Just one more thing: Wouldn't it make sense to mark {disp16} CpuNo64,
>> at least as long as it's not usable for controlling branch displacements
>> (which, as said, I think it shouldn't get enabled for)?
>
> Since {disp16} can only be used for memory reference in 16-bit mode,
> CpuNo64 isn't appropriate here.

Wouldn't the diagnostic be more to the point? (The prefix isn't limited
to 16-bit mode, but to 16-bit addressing, which can also be used from
32-bit mode, but not from 64-bit mode.)

Jan
Reply | Threaded
Open this post in threaded view
|

Re: V2 [PATCH] x86: Add {disp16} pseudo prefix

Sourceware - binutils list mailing list
On Fri, Jul 31, 2020 at 5:28 AM Jan Beulich <[hidden email]> wrote:

>
> On 31.07.2020 13:52, H.J. Lu wrote:
> > On Fri, Jul 31, 2020 at 12:03 AM Jan Beulich <[hidden email]> wrote:
> >>
> >> On 30.07.2020 01:39, H.J. Lu wrote:
> >>> Here is the updated patch.
> >>
> >> Just one more thing: Wouldn't it make sense to mark {disp16} CpuNo64,
> >> at least as long as it's not usable for controlling branch displacements
> >> (which, as said, I think it shouldn't get enabled for)?
> >
> > Since {disp16} can only be used for memory reference in 16-bit mode,
> > CpuNo64 isn't appropriate here.
>
> Wouldn't the diagnostic be more to the point? (The prefix isn't limited
> to 16-bit mode, but to 16-bit addressing, which can also be used from
> 32-bit mode, but not from 64-bit mode.)

It is checked with

          /* 32-bit/64-bit checks.  */
          if (i.disp_encoding == disp_encoding_16bit)
            {
            bad_disp:
              as_bad (_("invalid `%s' prefix"),
                      addr_mode == CODE_16BIT ? "{disp32}" : "{disp16}");
              return 0;
            }

and testcases are added.

--
H.J.
Reply | Threaded
Open this post in threaded view
|

Re: V2 [PATCH] x86: Add {disp16} pseudo prefix

Sourceware - binutils list mailing list
In reply to this post by Sourceware - binutils list mailing list
On Wed, Jul 29, 2020 at 4:39 PM H.J. Lu <[hidden email]> wrote:

>
> On Wed, Jul 29, 2020 at 3:53 PM H.J. Lu <[hidden email]> wrote:
> >
> > On Wed, Jul 29, 2020 at 1:26 PM Jan Beulich <[hidden email]> wrote:
> > >
> > > On 28.07.2020 22:30, H.J. Lu wrote:
> > > > On Tue, Jul 28, 2020 at 12:02 PM H.J. Lu <[hidden email]> wrote:
> > > >>
> > > >> On Tue, Jul 28, 2020 at 11:43 AM Jan Beulich <[hidden email]> 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.