MS/CW-style inline assembly for GCC

[Alex Rosenberg]

On May 6, 2004, at 5:57 PM, Oscar Fuentes wrote:

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

CW indeed does understand all of the inline asm instructions. It 
optimizes them and schedules them into the surrounding code. It even 
pays attention to potential global register defs and marks those 
instructions as not dead since a later asm block might use that reg. If 
anything, I find it a limitation of the current state of Stan's work 
that it doesn't go this extreme yet, but I'm more than happy with baby 
steps in this area.

GCC is the last compiler I'm using that doesn't have an integrated 
object file generator. It's way past time to integrate BFD, opcodes, 
etc. or whatever other solution to replace this 
generate-text-and-pipe-it-to-the-assembler '70s technology. That means 
one less thing on the host that may not match GCC's expectations. (e.g. 
AltiVec register names and the host assemblers)

The existing GCC asm syntax is truly HORRIBLE. Even among and entire 
team of kernel engineers and a handful of long-standing well-known GCC 
engineers I asked, nobody was able to come up with the right set of 
constraints and other undocumented and constantly changing voodoo that 
was necessary to accomplish a simple and correct solitary system call 
in a kernel test I wrote last year.

The CW syntax offers a sane alternative and the code to implement it 
already exists.

On May 6, 2004, at 6:40 PM, Mark Mitchell wrote:

> So, let's take truth-and-beauty out of the discussion; this isn't 
> about a better technology.  It might or might not be better, but 
> that's not the root of the issue.  The bottom line is that Apple wants 
> CW syntax because it wants to convert existing CW users to GCC users.  
> To do that, it wants to be able to say "you can just recompile your 
> code" rathern than "you have to rewrite your code".   In fact, for all 
> widely-used CW extensions, Apple would probably like to see them in 
> GCC.  It's easy to see the Apple product-marketing logic here.

This isn't about product-marketing. Hell, from the sound of it, they 
laid off that guy.

This is about Apple being a good GCC contributor, donating back it's 
changes, and doing the legwork necessary to make them fit well into the 
FSF tree. This is a positive change with massive ease-of-use payoffs 
for people who by necessity must use inline assembly. Show this syntax 
to some kernel folks -- once they get past their desire to maintain 
source compatibility with older GCCs, they'll want this syntax. 
Integrating this change into the FSF tree means that it can grow as it 
should -- perhaps into MSVC-compatible syntax or integrated object file 
generation, whatever. Limiting it to an Apple branch means that others 
cannot benefit from Stan's hard work and that would be a darn shame.

+------------------------------------------------------------+
| Alexander M. Rosenberg           <mailto:alexr@_spies.com> |
| Nobody cares what I say. Remove the underscore to mail me. |