This is the mail archive of the gcc@gcc.gnu.org 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


Richard Henderson wrote:

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.


CW allows jumps within the asm block, for which one synthesizes local
labels, but not outside, which I agree would be heinous.

(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?


I think CW only lets you use variables that are in registers. The
same problem must exist for GCC asm statements right? Presumably
the compiler kicks out your asm statement as invalid, because the
constraint can't be satisfied.


(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.

Is the killing of all registers required behavior? Seems not that
hard to detect the ones being clobbered and add them to the asm
statement's clobber list.

(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.

There are stupid CW asm users too, for instance 9-era TOC bits don't
carry over. But since #ifdef works in asm blocks, those parts can be
conditionalized.

In general I defined away a bunch of problems by only allowing the
functionality provided by GCC's asm statements. I wonder how useful
it would be to only support MS-style to the same level.

Stan


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