[Bug gas/10775] x86 64 documentation addenda

[hjl dot tools at gmail dot com]

------- Additional Comments From hjl dot tools at gmail dot com  2009-10-19 
17:08 -------
(In reply to comment #4)

> > 
> > movabs is not the only form to load a 64-bit literal into a register.
> 
> If there are other forms, where are they documented?

The normal "mov" insn:

mov $0x1ffffffff,%rax

works fine for me.

> > I don't think we want to go into such details here.
> 
> movabs is not an official Intel mnemonic.  Node (as.info)i386-Mnemonics
documents the detailed differences between Intel and AT&T syntax, so I don't
understand your reaction at all here.

movabs is only required only if you want a specific insn encoding
Otherwise, you can use "mov". Also movabs can also be used in

movabs 0x1ffffffff,%rax

which has a different meaning.

> > 
> > 
> > > The AT&T/Unixware assembler is documented at
> > > 
> > http://docs.sun.com/app/docs/doc/802-1948?l=en&q=assembler+manual and
> > > http://docs.sun.com/app/docs/doc/817-5477?l=en.
> 
> What harm comes of adding this?  The AT&T/Unixware assembler manual is not
available from SCO's site (makers of Unixware)---only from SUN; they also
defined the extensions to 64-bit mode.  Again, establishing this probably took
an hour or two.

Gas manual isn't a real x86 assembler reference. I always
point users to Sun's manual if they want to know the details.

> > > 
> > > In node (as.info)i386-Regs, before "* the 8 debug registers:" add
> > > * The processor control register `%cr8'.
> > > 
> > > At the end of that node, add
> > > 
> > > The 80386 flags register is not supported as a distinct 
> > register.  Instead, the
> > > instructions `PUSH [ER]?FLAGS' and `POP [EA]?FLAGS' are 
> > encoded as `pushf[wlq]'
> > > and `popf[wlq]'.
> > 
> > I don't think this belongs here. People should consult SDM when
> > writing assembly code.
> 
> The SDM uses the mnemonics PUSH EFLAGS and POP EFLAGS, but GAS in AT&T mode
does not support this syntax.  Reference to a register %eflags results in a GAS
assembler error.  Again, figuring this out took me maybe an hour.  What is being
documented here are the differences between the SDM and GAS.

My Intel64/ia32 SDM doesn't have PUSH EFLAGS nor POP EFLAGS.
It only has pushf/popf.


> > 
> > > After node (as.info)i386-16bit, add a new section:
> > > 
> > > 9.13.13 Writing 64-bit Code
> > > ---------------------------
> > > The `.code64' directive causes the assembler to emit AMD64 
> > ``long mode''
> > > (64-bit) code.  As mentioned above, the `.code32' directive 
> > switches to 32-bit
> > > code.  Which mode the assembler is in originally depends on 
> > the --32 and --64
> > > options.
> > 
> > I will check in this patch.
> > 
> > diff --git a/gas/doc/c-i386.texi b/gas/doc/c-i386.texi
> > index cf0bfa8..50e6e98 100644
> > --- a/gas/doc/c-i386.texi
> > +++ b/gas/doc/c-i386.texi
> > @@ -513,6 +513,9 @@ the 4 8-bit registers: @samp{%sil}, 
> > @samp{%dil}, @samp{%bpl}
> > , @samp{%spl}.
> >  the 8 debug registers: @address@hidden
> >  
> >  @item
> > +the 8 control registers: @address@hidden
> 
> Does GAS really support cr9--cr15?  These registers are currently not
documented by the SDM.

Gas supports r0 to r15. But not all of them are valid, like
CR1, CR5, CR6, CR7, and CR9–CR15. I will revert it. People
should read SDM when accessing them.

> 
> Documenting how to generate 64-bit code in a section entitled "Writing 16-bit
Code" seems suboptimal.
> 

Please feel free to submit a patch.  Thanks.


-- 


http://sourceware.org/bugzilla/show_bug.cgi?id=10775

------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.