That's called as(1).
On any architecture with a non-trivial register allocation, the above
statement does not apply.
As far as performance goes you might be better off not using assembler
to begin with.
Exactly. If you want asm, you know where to find it. These days, the
cases where raw assembler really matters are significant enough that a few
in-lines generally don't accomplish anything. Yes, you can pollute your C
code with __asm(), but I could also argue for _f77() so that I could
compile spice (or more importantly, dungeon) with cc. Where does it end?
Compilers (at least the ones I work on) are quite smart
in how they use precious resource such as registers, and unless you
can hide everything away on the other side of the 'call' op you'd
be in trouble mixing your code with what compiler had generated for
you.
Sure, the compiler can assist with register allocation, but so can reading
the ABI documentation. Once upon a time I spent way too much of my life
optimizing MIPS cycles out of the distributed.net client instead of
drinking beer. After watching the compilers blow away almost all of the
machine code optimizations people proposed, I filed great chunks of
in-lined cruft in the bin. The only asm code that mattered was the
carefully tuned *long* unrolled loop bit-shifting stuff. And it had an
execution time that made the call overhead invisible.
GCC style asm in-lines play nice with things like register
allocator and instruction scheduler, where .s files don't.
Only in the cases where asm code doesn't provide enough benefit to be
worthwhile.
What's 3B3 and ESS#5 ? ;-)
A reasonable telephone switch billing system, and the worlds worst
multi-user UNIX timeshare box. Perhaps not in that order. (Or maybe it
*is* the right order.)
--lyndon
In God we Trust -- all others must submit an X.509 certificate.
-- Charles Forsythe
