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


Andrew Pinski wrote:


I have the view now that any use of inline-asm is usually wrong except when
the instruction is not avialable to compiler to use such as mftbu/mftb and
instructions which implement atomic operations (but then again there is
already a request for builtins for the atomic operations, PR 14311).
And there could be target dependent builtins for most other things such as
mftbu/mftb.


That argument doesn't get very far with the programmers who
know more than you or I about assembly-level optimization; all
they do is file a bunch of bug reports about missed optimizations
that will take a decade to implement in GCC, and say "get back
to us when you've got all that working." The original GCC manual
confidently declared that it would be so good that there would
no longer be much need for inline asm; fifteen years later, the
QuickTime guys are still waiting. :-)

Also the MS/CW style of inline-asm will cause more problems as how would you know
what registers to mark as clobber and if the memory is clobbered? Do you mark them
all as clobbered except for a select few or do you need to parse the asm too which
in that case we really need to start thinking about integrating gas into GCC
like any commercial compiler already does. I think this is best approach any ways
except that some targets are not yet supported by fully gas (like Darwin and IIRC AIX).

All the operands are parsed, so random register references are recognized as such. If you had to think about implicitly clobbered registers, you'd have to go back to the original GCC syntax or do something else; this is a simplified syntax, and so in exchange you do have to give up some expressive power.

Stan


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