This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: MS/CW-style inline assembly for GCC

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

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]