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 May 6, 2004, at 5:57 PM, Oscar Fuentes wrote:

Mark Mitchell <> writes:


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           <> |
| Nobody cares what I say. Remove the underscore to mail me. |

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