This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: MS/CW-style inline assembly for GCC
Mark Mitchell wrote:
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?
For me, compatibility is the number one priority. Ease of use comes
into play because the CW syntax really is easier to use; GCCers add
a lot of warts to the compiler in order to make it more compatible
with others, but I don't think this extension is in the wart category.
It's almost comical to have people working so hard to rationalize the
GCC syntax; if you sat a bunch of users down with the different
syntaxes, and said "which do you prefer?" do you really think they
would choose the GCC syntax over the CW syntax?
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.)
The CW asm block is single-entry, single-exit - it enforces by having
special syntax for labels internal to the block, and you're not
allowed to refer to C-language labels (I tried). Memory clobbering
issues are the same as for asm statements today, and registers it
knows about because it parses all the operands. Implicitly clobbered
registers would be more work, but worth it - that is another
limitation of the GCC asm statement that drives users crazy.
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.
Ick, that's pretty sadistic. GCC already knows the best things to
do with local variables and registers, as a user I don't want to
order it to do something bad, I want it to help me out by applying
that knowledge to my inline asm instructions.
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.
Handling as a block gives you effective preprocessing and debugging
(which I forgot to mention as a win before - GDB enjoys single
stepping through CW-style inline asm blocks), so that's certainly
a worthwhile step.
(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.
Since when has anybody had a hard time saying no around here? :-)
Handling functionality through FSF process instead of a support
contract also has the nice property that you can say yes to the good
stuff and no to the bad stuff. Plus you're not under a deadline to
make the compiler accept the crappiest user code ever written, so
you can say "if MS didn't define the semantics, neither will we"
instead of twisting GCC into a pretzel.
Stan