On 24/04/13 11:41, dw wrote: > I found the existing docs for extended asm to be unclear and > incomplete. Rather than just complain and hope someone would fix them, > I have re-written them myself. > > In general, I wrote a framework to describe the instruction, then > cut/pasted the existing text into the appropriate places in the new > doc. This has resulted in a complete re-write of section 6.41 > (http://gcc.gnu.org/onlinedocs/gcc-4.8.0/gcc/Extended-Asm.html) as well > as a few new sub-sections. > > I have generated a patch file for extend.texi > (http://www.LimeGreenSocks.com/gcc/extend.texi.patch), or you can > (temporarily) view the html at > http://www.limegreensocks.com/gcc/Extended-Asm.html. > > No doubt I have violated a dozen of the gcc doc standards, but I believe > that overall, the content and format of the changes are a huge > improvement over the existing text. > > Please let me know what I need to do to have this patch accepted. > > dw > I've only had a very brief look at the page so far (as others have said, there is a lot there). But one thing I note is that you seem to have examples from a variety of target processors, which is a very nice point, but that you are not very clear about /which/ processor is used in each example. It can also help to say what the assembly instructions actually /do/. I think a lot of people looking for help with inline assembly will be people working with embedded processors - it is more common for "normal" programmers to have to do a little bit of inline assembly in the embedded world. So it is good to include examples for such processors. You might like to look at <http://www.nongnu.org/avr-libc/user-manual/inline_asm.html> for inspiration. One thing I think would be nice for the complex examples is to show the actual generated assembly code (from the ".s" file, or from an assembly listing file). I would also like to see a lot more emphasis on symbolic names (%[var] rather than %0) - I think it is a style that can be more intelligible, and is therefore often the best choice. /Writing/ inline assembly is often quite hard - but /reading/ it is often even harder. Names rather than numbers can help here. mvh., David
