Re: MS/CW-style inline assembly for GCC

[Mark Mitchell <mark at codesourcery dot com>]

Stan Shebs wrote:

> > (2) We already have inline assembly.  When we have two ways of doing 
> > something, then we have to worry about consistency between them, 
> > additional documentation, etc., etc.  As has been suggested, it would 
> > seem better to improve the documentation and/or code for the current 
> > version.  If this were purely a syntactic extension that would be one 
> > thing (i.e., if the new syntax could be mapped directly on to the old 
> > syntax in a simple, platform-independent way), but that is not the case.
> A purely syntactic extension would be kind of pointless - what this
> syntax does is to simplify and automate the parts of GCC assembly
> syntax that are known to be extremely difficult for users to get right,
> which also happens to facilitate porting code that could previously
> only be handled by a proprietary compiler. So it does require a small
> amount of platform support, namely to compute the arcana that has been
> exposed to the poor users.

I do sympathesize with what you're saying here.

Which part of the goal is more important to you?  The compatiblity with 
the proprietary compiler, or the abstract ease-of-use?

The key problems with inline assembly schemes are (a) allowing the 
assembly to access local variables in the containing code, and (b) 
describing the effects of the assembly code to the optimizers.  GCC adds 
complexity by trying to let the compiler do register allocation for the 
programmer.

It's relatively easy to deal with "b" -- you can pick maximally 
conservative assumptions for the easy-to-use assembly syntax.   (All 
memory is read, all memory is written, all registers are read, all 
registers are written, control flow can go to any label from here, etc.)

To do "a", you could require that all non-global symbols accessed from 
the assembly code be explicitly placed in a register with GCC's existing 
"register" extension.  And, then, access them by their register name in 
the inline assembly.  If you did this, you'd need basically no compiler 
support; the assembly code would just be a long block of code that got 
dumped into the output file.  Now, we've already got that -- at least 
almost -- in the form of:

 __asm__ volatile ("/* big block 'o code */")

I'd not be opposed to allowing you to spell that:

 asm {
   /* big block o' code */
 }

which would be somewhat simpler for users.    It might be that the fully 
conservative assumptions I'm suggesting would require more than just the 
current "asm __voaltile__" semantics, but that shouldn't be too hard to 
arrange.

I suspect, however, that what you're *really* after is CW-compatibility.

> > (3) Some of our most experienced contributors have expressed deep 
> > reservations, based on prior implementation experience, relating to 
> > this feature.
> If you mean Richard, did you see his last message? His objections were
> to MS compatibility on the basis of issues that don't come up with the
> CW-compatible extension, and I'm perfectly happy not to bother with
> MS compatibility

Although that *will* come up once we have compatibility with CW.  In 
fact, every inline assembler syntax ever invented will then become a 
candidate for addition to GCC.   Certainly, all the user-level issues 
about why it is good to add the CW syntax also apply to the MS syntax, 
even though technically it might be harder to do one than the other.  
So, someone will come along with a mostly-working MS-syntax patch, and 
it will help a lot of Windows code compile, and then we're going to have 
a very hard time saying no.

--
Mark Mitchell
CodeSourcery, LLC
(916) 791-8304
mark@codesourcery.com