i386: Document memory size reference in assembler

Message ID B1254C1F3D65A641B4143C8E9793D9FD481580DF@shsmsx102.ccr.corp.intel.com
State New
Headers show
Series
  • i386: Document memory size reference in assembler
Related show

Commit Message

Cui, Lili June 24, 2019, 3:30 a.m.
Hi all,

This patch is about to Document x/y/z instruction sufffixes in AT&T syntax and 
xmmword/ymmword/zmmword/fword/tword/oword ptr in Intel syntax in binutils .


gas/ChangeLog:

2019-06-21  Lili Cui  <lili.cui@intel.com>

            * doc/c-i386.texi: Document x/y/z instruction sufffixes in AT&T
            syntax and xmmword/ymmword/zmmword/fword/tword/oword ptr in
            Intel syntax
---
gas/doc/c-i386.texi | 16 ++++++++++------
1 file changed, 10 insertions(+), 6 deletions(-)

-- 
2.17.1

Thanks,
Lili.

Comments

Jan Beulich June 24, 2019, 7:05 a.m. | #1
>>> On 24.06.19 at 05:30, <lili.cui@intel.com> wrote:

> --- a/gas/doc/c-i386.texi

> +++ b/gas/doc/c-i386.texi

> @@ -583,12 +583,16 @@ instruction, do @emph{not} have reversed order.  

> @ref{i386-Bugs}.

> @item

> In AT&T syntax the size of memory operands is determined from the last

> character of the instruction mnemonic.  Mnemonic suffixes of @samp{b},

> -@samp{w}, @samp{l} and @samp{q} specify byte (8-bit), word (16-bit), long

> -(32-bit) and quadruple word (64-bit) memory references.  Intel syntax accomplishes

> -this by prefixing memory operands (@emph{not} the instruction mnemonics) with

> -@samp{byte ptr}, @samp{word ptr}, @samp{dword ptr} and @samp{qword ptr}.  Thus,

> -Intel @samp{mov al, byte ptr @var{foo}} is @samp{movb @var{foo}, %al} in AT&T

> -syntax.

> +@samp{w}, @samp{l}, @samp{q}, @samp{x}, @samp{y} and @samp{z} specify

> +byte (8-bit), word (16-bit), long (32-bit), quadruple word (64-bit),

> +xmm (128-bit vector), ymm (256-bit vector) and zmm (512-bit vector)

> +memory references.  Intel syntax accomplishes this by prefixing memory

> +operands (@emph{not}the instruction mnemonics) with @samp{byte ptr},

> +@samp{word ptr}, @samp{dword ptr}, @samp{qword ptr}, @samp{xmmword ptr},

> +@samp{ymmword ptr} and @samp{zmmword ptr}.  Thus, Intel syntax

> +@samp{mov al, byte ptr @var{foo}} is @samp{movb @var{foo}, %al} in

> +AT&T syntax.  In Intel syntax, @samp{fword ptr}, @samp{tword ptr} and

> +@samp{oword ptr} specify 48-bit, 80-bit and 128-bit memory references.


This makes it sound as if the x/y/z suffixes were universally applicable,
just like the b/w/d/q ones are, but that's not the case: They're used
(permitted) only when there's no other way to disambiguate an insn.

Jan
Cui, Lili June 25, 2019, 8:56 a.m. | #2
Update patch,  separate suffix x/y/z with b/w/d/q .


-----Original Message-----
From: Jan Beulich [mailto:JBeulich@suse.com] 

Sent: Monday, June 24, 2019 3:05 PM
To: Cui, Lili <lili.cui@intel.com>
Cc: Zhang, Annita <annita.zhang@intel.com>; Lu, Hongjiu <hongjiu.lu@intel.com>; Liu, Hongtao <hongtao.liu@intel.com>; Xiao, Wei3 <wei3.xiao@intel.com>; binutils@sourceware.org
Subject: Re: i386: Document memory size reference in assembler

>>> On 24.06.19 at 05:30, <lili.cui@intel.com> wrote:

> --- a/gas/doc/c-i386.texi

> +++ b/gas/doc/c-i386.texi

> @@ -583,12 +583,16 @@ instruction, do @emph{not} have reversed order.  

> @ref{i386-Bugs}.

> @item

> In AT&T syntax the size of memory operands is determined from the last 

> character of the instruction mnemonic.  Mnemonic suffixes of @samp{b}, 

> -@samp{w}, @samp{l} and @samp{q} specify byte (8-bit), word (16-bit), 

> long

> -(32-bit) and quadruple word (64-bit) memory references.  Intel syntax 

> accomplishes -this by prefixing memory operands (@emph{not} the 

> instruction mnemonics) with -@samp{byte ptr}, @samp{word ptr}, 

> @samp{dword ptr} and @samp{qword ptr}.  Thus, -Intel @samp{mov al, 

> byte ptr @var{foo}} is @samp{movb @var{foo}, %al} in AT&T -syntax.

> +@samp{w}, @samp{l}, @samp{q}, @samp{x}, @samp{y} and @samp{z} specify 

> +byte (8-bit), word (16-bit), long (32-bit), quadruple word (64-bit), 

> +xmm (128-bit vector), ymm (256-bit vector) and zmm (512-bit vector) 

> +memory references.  Intel syntax accomplishes this by prefixing 

> +memory operands (@emph{not}the instruction mnemonics) with @samp{byte 

> +ptr}, @samp{word ptr}, @samp{dword ptr}, @samp{qword ptr}, 

> +@samp{xmmword ptr}, @samp{ymmword ptr} and @samp{zmmword ptr}.  Thus, 

> +Intel syntax @samp{mov al, byte ptr @var{foo}} is @samp{movb 

> +@var{foo}, %al} in AT&T syntax.  In Intel syntax, @samp{fword ptr}, 

> +@samp{tword ptr} and @samp{oword ptr} specify 48-bit, 80-bit and 128-bit memory references.


This makes it sound as if the x/y/z suffixes were universally applicable, just like the b/w/d/q ones are, but that's not the case: They're used
(permitted) only when there's no other way to disambiguate an insn.

Jan
Jan Beulich June 25, 2019, 9:07 a.m. | #3
>>> On 25.06.19 at 10:56, <lili.cui@intel.com> wrote:

> Update patch,  separate suffix x/y/z with b/w/d/q .


Better, but there are still issues: For one you need to look at your
formatting. I think there are a number of blanks missing. You also
start re-flowing existing text a little too early (but that's minor, it
just makes the diff bigger than it needs to be). And then you add
mention of "tword" which I think you mean to be "tbyte".

Also - please don't top-post.

Jan
Cui, Lili June 26, 2019, 3:37 a.m. | #4
> -----Original Message-----

> From: Jan Beulich [mailto:JBeulich@suse.com]

> Sent: Tuesday, June 25, 2019 5:07 PM

> To: Cui, Lili <lili.cui@intel.com>

> Cc: Zhang, Annita <annita.zhang@intel.com>; Lu, Hongjiu

> <hongjiu.lu@intel.com>; Liu, Hongtao <hongtao.liu@intel.com>; Xiao, Wei3

> <wei3.xiao@intel.com>; binutils@sourceware.org

> Subject: RE: i386: Document memory size reference in assembler

> 

> >>> On 25.06.19 at 10:56, <lili.cui@intel.com> wrote:

> > Update patch,  separate suffix x/y/z with b/w/d/q .

> 

> Better, but there are still issues: For one you need to look at your formatting.

> I think there are a number of blanks missing. You also start re-flowing

> existing text a little too early (but that's minor, it just makes the diff bigger

> than it needs to be). And then you add mention of "tword" which I think you

> mean to be "tbyte".

> 

> Also - please don't top-post.

> 

> Jan

> 

Update patch, thanks for your careful examination, I modified the formatting and changed "tword" to "tbyte". Thanks.

#define I386_TYPE(t, n) { #t, O_##t##_ptr, { n, n, n } }
    I386_TYPE(byte, 1),
    I386_TYPE(word, 2),
    I386_TYPE(dword, 4),
    I386_TYPE(fword, 6),
    I386_TYPE(qword, 8),
    I386_TYPE(tbyte, 10), 
    I386_TYPE(oword, 16), 
    I386_TYPE(xmmword, 16), 
    I386_TYPE(ymmword, 32), 
    I386_TYPE(zmmword, 64),
Jan Beulich June 26, 2019, 8:12 a.m. | #5
>>> On 26.06.19 at 05:37, <lili.cui@intel.com> wrote:

> Update patch, thanks for your careful examination, I modified the formatting 

> and changed "tword" to "tbyte". Thanks.


Thanks, lgtm now. I'm not the one to approve it though.

> #define I386_TYPE(t, n) { #t, O_##t##_ptr, { n, n, n } }

>     I386_TYPE(byte, 1),

>     I386_TYPE(word, 2),

>     I386_TYPE(dword, 4),

>     I386_TYPE(fword, 6),

>     I386_TYPE(qword, 8),

>     I386_TYPE(tbyte, 10), 

>     I386_TYPE(oword, 16), 

>     I386_TYPE(xmmword, 16), 

>     I386_TYPE(ymmword, 32), 

>     I386_TYPE(zmmword, 64),


No idea what this is about.

Jan
Cui, Lili June 26, 2019, 8:18 a.m. | #6
> -----Original Message-----

> From: Jan Beulich [mailto:JBeulich@suse.com]

> Sent: Wednesday, June 26, 2019 4:13 PM

> To: Cui, Lili <lili.cui@intel.com>

> Cc: Zhang, Annita <annita.zhang@intel.com>; Lu, Hongjiu

> <hongjiu.lu@intel.com>; Liu, Hongtao <hongtao.liu@intel.com>; Xiao, Wei3

> <wei3.xiao@intel.com>; binutils@sourceware.org

> Subject: RE: i386: Document memory size reference in assembler

> 

> >>> On 26.06.19 at 05:37, <lili.cui@intel.com> wrote:

> > Update patch, thanks for your careful examination, I modified the

> > formatting and changed "tword" to "tbyte". Thanks.

> 

> Thanks, lgtm now. I'm not the one to approve it though.

> 

> > #define I386_TYPE(t, n) { #t, O_##t##_ptr, { n, n, n } }

> >     I386_TYPE(byte, 1),

> >     I386_TYPE(word, 2),

> >     I386_TYPE(dword, 4),

> >     I386_TYPE(fword, 6),

> >     I386_TYPE(qword, 8),

> >     I386_TYPE(tbyte, 10),

> >     I386_TYPE(oword, 16),

> >     I386_TYPE(xmmword, 16),

> >     I386_TYPE(ymmword, 32),

> >     I386_TYPE(zmmword, 64),

> 

> No idea what this is about.

> 

> Jan

> 

It means that there is no type of "twod", only "tbyte" here.
H.J. Lu June 26, 2019, 10:11 p.m. | #7
On Wed, Jun 26, 2019 at 1:18 AM Cui, Lili <lili.cui@intel.com> wrote:
>

>

>

> > -----Original Message-----

> > From: Jan Beulich [mailto:JBeulich@suse.com]

> > Sent: Wednesday, June 26, 2019 4:13 PM

> > To: Cui, Lili <lili.cui@intel.com>

> > Cc: Zhang, Annita <annita.zhang@intel.com>; Lu, Hongjiu

> > <hongjiu.lu@intel.com>; Liu, Hongtao <hongtao.liu@intel.com>; Xiao, Wei3

> > <wei3.xiao@intel.com>; binutils@sourceware.org

> > Subject: RE: i386: Document memory size reference in assembler

> >

> > >>> On 26.06.19 at 05:37, <lili.cui@intel.com> wrote:

> > > Update patch, thanks for your careful examination, I modified the

> > > formatting and changed "tword" to "tbyte". Thanks.

> >

> > Thanks, lgtm now. I'm not the one to approve it though.

> >

> > > #define I386_TYPE(t, n) { #t, O_##t##_ptr, { n, n, n } }

> > >     I386_TYPE(byte, 1),

> > >     I386_TYPE(word, 2),

> > >     I386_TYPE(dword, 4),

> > >     I386_TYPE(fword, 6),

> > >     I386_TYPE(qword, 8),

> > >     I386_TYPE(tbyte, 10),

> > >     I386_TYPE(oword, 16),

> > >     I386_TYPE(xmmword, 16),

> > >     I386_TYPE(ymmword, 32),

> > >     I386_TYPE(zmmword, 64),

> >

> > No idea what this is about.

> >

> > Jan

> >

> It means that there is no type of "twod", only "tbyte" here.


I am checking it in for you.

Thanks.

-- 
H.J.
Cui, Lili June 27, 2019, 1:29 a.m. | #8
> -----Original Message-----

> From: H.J. Lu [mailto:hjl.tools@gmail.com]

> Sent: Thursday, June 27, 2019 6:11 AM

> To: Cui, Lili <lili.cui@intel.com>

> Cc: Jan Beulich <JBeulich@suse.com>; Zhang, Annita

> <annita.zhang@intel.com>; Lu, Hongjiu <hongjiu.lu@intel.com>; Liu,

> Hongtao <hongtao.liu@intel.com>; Xiao, Wei3 <wei3.xiao@intel.com>;

> binutils@sourceware.org

> Subject: Re: i386: Document memory size reference in assembler

> 

> On Wed, Jun 26, 2019 at 1:18 AM Cui, Lili <lili.cui@intel.com> wrote:

> >

> >

> >

> > > -----Original Message-----

> > > From: Jan Beulich [mailto:JBeulich@suse.com]

> > > Sent: Wednesday, June 26, 2019 4:13 PM

> > > To: Cui, Lili <lili.cui@intel.com>

> > > Cc: Zhang, Annita <annita.zhang@intel.com>; Lu, Hongjiu

> > > <hongjiu.lu@intel.com>; Liu, Hongtao <hongtao.liu@intel.com>; Xiao,

> > > Wei3 <wei3.xiao@intel.com>; binutils@sourceware.org

> > > Subject: RE: i386: Document memory size reference in assembler

> > >

> > > >>> On 26.06.19 at 05:37, <lili.cui@intel.com> wrote:

> > > > Update patch, thanks for your careful examination, I modified the

> > > > formatting and changed "tword" to "tbyte". Thanks.

> > >

> > > Thanks, lgtm now. I'm not the one to approve it though.

> > >

> > > > #define I386_TYPE(t, n) { #t, O_##t##_ptr, { n, n, n } }

> > > >     I386_TYPE(byte, 1),

> > > >     I386_TYPE(word, 2),

> > > >     I386_TYPE(dword, 4),

> > > >     I386_TYPE(fword, 6),

> > > >     I386_TYPE(qword, 8),

> > > >     I386_TYPE(tbyte, 10),

> > > >     I386_TYPE(oword, 16),

> > > >     I386_TYPE(xmmword, 16),

> > > >     I386_TYPE(ymmword, 32),

> > > >     I386_TYPE(zmmword, 64),

> > >

> > > No idea what this is about.

> > >

> > > Jan

> > >

> > It means that there is no type of "twod", only "tbyte" here.

> 

> I am checking it in for you.

> 

> Thanks.

> 

> --

> H.J.


Thank you, H.J.

Thanks,
Lili.

Patch

diff --git a/gas/doc/c-i386.texi b/gas/doc/c-i386.texi
index 9d821ae8e7..a1af6ca4ae 100644
--- a/gas/doc/c-i386.texi
+++ b/gas/doc/c-i386.texi
@@ -583,12 +583,16 @@  instruction, do @emph{not} have reversed order.  @ref{i386-Bugs}.
@item
In AT&T syntax the size of memory operands is determined from the last
character of the instruction mnemonic.  Mnemonic suffixes of @samp{b},
-@samp{w}, @samp{l} and @samp{q} specify byte (8-bit), word (16-bit), long
-(32-bit) and quadruple word (64-bit) memory references.  Intel syntax accomplishes
-this by prefixing memory operands (@emph{not} the instruction mnemonics) with
-@samp{byte ptr}, @samp{word ptr}, @samp{dword ptr} and @samp{qword ptr}.  Thus,
-Intel @samp{mov al, byte ptr @var{foo}} is @samp{movb @var{foo}, %al} in AT&T
-syntax.
+@samp{w}, @samp{l}, @samp{q}, @samp{x}, @samp{y} and @samp{z} specify
+byte (8-bit), word (16-bit), long (32-bit), quadruple word (64-bit),
+xmm (128-bit vector), ymm (256-bit vector) and zmm (512-bit vector)
+memory references.  Intel syntax accomplishes this by prefixing memory
+operands (@emph{not}the instruction mnemonics) with @samp{byte ptr},
+@samp{word ptr}, @samp{dword ptr}, @samp{qword ptr}, @samp{xmmword ptr},
+@samp{ymmword ptr} and @samp{zmmword ptr}.  Thus, Intel syntax
+@samp{mov al, byte ptr @var{foo}} is @samp{movb @var{foo}, %al} in
+AT&T syntax.  In Intel syntax, @samp{fword ptr}, @samp{tword ptr} and
+@samp{oword ptr} specify 48-bit, 80-bit and 128-bit memory references.

 In 64-bit code, @samp{movabs} can be used to encode the @samp{mov}
instruction with the 64-bit displacement or immediate operand.