Re: [9fans] speaking of kenc

[Lyndon Nerenberg <lyndon@orthanc.ca>]

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