------- 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: @samp{%db8...@samp{%db15}. > > > > @item > > +the 8 control registers: @samp{%cr8...@samp{%cr15}. > > 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 CR9CR15. 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. _______________________________________________ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
