Re: MS/CW-style inline assembly for GCC

[Richard Henderson <rth at redhat dot com>]

On Mon, May 03, 2004 at 05:35:40PM -0700, Stan Shebs wrote:
> Can you be more specific about the difficulties?

(1) Control flow.  MSVC allows branches to leave the asm block,
    something that doesn't map onto existing gcc asm blocks.
    The hack we had for this was truely odious.

(2) Spill code within asm blocks.  What do you do if the data
    that the user is accessing in some instruction isn't 
    directly addressable?  On x86, in non-pic mode, you can
    /almost/ always use either memory or registers.  But when
    that's not the case -- and it does happen -- what do you
    do about generating correct code?

    What we actually did mostly kinda sorta worked.  The only
    way I can see you can get this to work 100% is to parse
    the inline assembly into rtl that means the same thing and
    let the register allocator dtrt.  At which point as far as
    I'm concerned you might as well have written the damned thing
    in C in the first place.

(3) Data flow across the asm block.  IIRC, MSVC just assumes the
    block kills all live registers.  The result is that optimization
    around these blocks is abysmal.  Much much MUCH worse than
    similar code written in C.  Which of course leads to the naked
    function disgustingness as a workaround.

(4) PIC code.  Stupid users write inline assembly that clobbers
    ebx and then somehow expect to be able to use -fpic and put
    the result in a Linux elf shared library.

    This probably doesn't affect darwin much, but it definitely
    affects MSVC on Linux, which folks will expect if you do
    MSVC for darwin/x86.

And probably other things that my brain has purged.


r~