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

On Tue, 4 May 2004, Richard Henderson wrote:

> On Tue, May 04, 2004 at 11:19:12AM -0700, Stan Shebs wrote:
> > CW allows jumps within the asm block, for which one synthesizes local
> > labels, but not outside, which I agree would be heinous.
> Not too bad...
> > 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.
> That's what happens with gcc asms, yes.  It was much less clear
> what to do about msvc asms, mostly due to lack of registers, the
> pressure added by x86 elf -fpic code, and (perhaps unreasonable)
> customer expectation that it "just work".
> I presume you're also parsing the asm opcode to know what register
> class is needed at a particular point?
> > 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.
> I think so, yes.  I don't recall the details; probably some
> customer test case that accidentally worked with msvc.

I can think of trivial examples.

If a user uses eax in their code, it's no guarantee that it's clobbered,
because he can do:

push eax
pop eax

in which case it's not clobbered, and you wind up unnecessarily assuming
it's clobbered, and saving and restoring registers, which partially
defeats the point of using inline assembly in the first place.

However, pushing and popping eax is not guarantee that it's being saved
either, because the user might do:

push eax
push ebx
pop eax
pop ebx

in which case eax and ebx are clobbered.

Really, if you try to parse the assembly and infer the register
clobbers, you're trying to solve the halting problem.

The same problem occurs for memory stores as well. You can't tell if
memory should be clobbered just because there is a store in the code.

For example, if you're writing to a memory-mapped hardware register which
is not compiler-visible, then there's no reason to clobber memory.
However, if the compiler parses the inline assembly to determine memory
clobbers, there's no way it can know this, so it winds up clobbering
memory unnecessarily.

When I worked at Sega, I received a lot of questions about the inline
assembly syntax, so I wrote a longish document for GCC SH4 inline
assembly. Once users understood the power of the GCC inline assembly
syntax, they were generally very enthusiastic about it.

Personally, I hate the MSVC syntax as well.


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