Re: [DOC PATCH] Rewrite docs for inline asm

[dw <limegreensocks@yahoo.com>]

While I'm waiting to hear back from Gerald about my responses to his 
other corrections, I have answered one question:

> How does the user know what is dialect #0?  Same for the others?
>
> When I originally wrote that section, I didn't know the answer (which 
> is why I left it vague).  Now I think I do, but I'd like someone to 
> confirm.  On my builds of gcc, the dialects are listed (in dialect 
> order) under "Known assembler dialects" in "gcc --target-help".  Can I 
> rely on this enough to put it in the docs? Is there some better source?

First of all, -masm is (currently) only supported on i386: 
http://gcc.gnu.org/onlinedocs/gcc/Option-Summary.html

Second, i386 -masm only supports two options: 
http://gcc.gnu.org/onlinedocs/gcc/i386-and-x86-64-Options.html

So, the inline asm docs could just say "att" and "intel."  However, 
there's a difference between using "intel" and "att" as examples of how 
dialects work, and "hard coding" these names into this section as the 
list of available options.  I'm not keen on putting machine-specific 
info like this into an otherwise machine-neutral section.

Such being the case, I replaced the previously vague paragraph with:

GCC may support multiple assembler dialects (such as "att" or "intel") for
inline assembler. In builds that support this capability, the 
@option{-masm}
option controls which dialect GCC uses as its default. The 
hardware-specific
documentation for the @option{-masm} option contains the list of supported
dialects, as well as the default dialect if the option is not specified. 
This
information may be important to understand, since assembler code that works
correctly when compiled using one dialect will likely fail if compiled 
using
another.

This keeps the machine-specific details with the already 
machine-specific compile options.  While this option only applies to 
i386 currently, this text leaves the option open should some other 
platform make use of it in the future.

Unless someone says otherwise, I'm calling this question resolved.

dw