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 <mark@codesourcery.com> writes:
[snip]
> 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.
Why do you insist on describing the effects to the optimizers for
achieving *compatibility* with other vendors? Some messages on this
thread assumes that MS/CW have some magic mechanism for producing
optimized code on the presence of inline asm, by means of
"understanding" what the asm does. I don't know about CW, but the MS
docs basically says that the compiler assumes the worse case and, if
the compiler fails to do that, the programmer is guilty. See below.
[snip]
> 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.)
That would be ok for those people who need to port software to/from
GCC. The problem is not only the arcane GCC syntax, but rewriting and
duplicating the maintenance of very delicate code.
> 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.
Uh? First, this defeats compatibility. Second, what about x86 and its
tiny register set? Is it really so difficult to allocate a stack slot
for every variable accessed on the asm block and ensure that the
variable's value is stored on its slot before entering the asm block?
[snip]
>>> (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
I would thank Mr. Richard Henderson if he shows me some URL
documenting the "magic" MS does with its asm blocks. I found
none. Quite the contrary. What MS seems to do, essentially, is:
1) Replace usage of C symbols and MASM expressions with its pure asm
expressions:
__asm mov eax, local_var;
__asm add eax, SIZEOF(some_data);
__asm call _printf;
with
mov eax, [sp-X]
add eax, 4
call _printf
etc
2) Make sure that registers are flushed to memory before entering the
asm block.
3) After exiting the asm block, if in doubt, assume memory is
dirty. Assume certain (documented) registers are dirty. If you use
ebx, esi or edi registers, the compiler generates a *function*
prologue/epilogue code for saving them, in case it doesn't already
exists.
4) Finally, the asm block is "inserted" within the rest of the
function code.
If you do crazy things like tampering with BP, SP, the direction flag,
etc, you are responsible to revert everything to a sane state before
exiting the asm block. If you insert asm blocks inside functions with
special calling conventions (__fastcall, for instance), you must take
special care of not messing up things.
Some people here says that the "good thing" is to use an
assembler. This only shows lack of imagination or experience wrt
inline asm. Please don't use the argument of "you think you need that
feature because you are a undereducated". Is offensive.
[snip]
--
Oscar