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



On May 3, 2004, at 18:16, Stan Shebs wrote:


However, the syntax has also been somewhat inaccessible. Those
constraint letters were often undocumented, and are still somewhat
mysterious to users, while the use of strings for instructions makes
the construction of longer assembly sequences a rather difficult
undertaking. In addition, the "capture" of GCC's constraint letters
and pattern syntax into source code has the potential to reduce our
flexibility to change compiler internals later.

If the constraint letters are undocumented either they should be removed
or documented. Or really documented better as they are documented weakly
now.


Now on the other hand operand operators are not documented but most people
do not use them and should not be used at all.


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.


And if the people wants to program in asm, they should not be using a
compiler to do the work.

And then only the few will need ever inline-asm. In fact for IA64, inline-asm
is discerned as getting the instruction packet just right is very prone to bugs.


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


Thanks,
Andrew Pinski


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