Re: A Fateman paper

sfuerst wrote:
THEN you have a case for using assembly language.

In other words, almost never.


Actually, the use of assembly language is a little more common than
that. Sometimes you just have to use it. The biggest case is when
you need to use functionality of your processor that isn't exported by
the C language.

Eamples of this are:
i/o instructions that talk to hardware.
atomic and memory barrier instructions, so parallel primitives can be
written.

Unless they are exposed as extensions, yes you can need assembler to deal with those.

Things that deal with or create calling conventions: i.e. creating a
user-space threading library needs some way of expressing and
implementing a stack-switch.

Again, although you only write such things rarely.

Calling a C++ member function pointer
from C requires an asm thunk to get the parameters in the right
registers/stack slots.

Ask over in comp.lang.c++ and they will explain how to call C++ from C without resorting to such fragile and dirty tricks.

The other case is where performance is part of the specification.
There, you are forced to use assembly to access instructions that
otherwise are not emitted by the C compiler.

Sometimes, yes, but modern compilers are often pretty good at this...

Examples of this are:
Vectorization, SSE, SSE2, Altivec etc. (compiler intrinsics help, but
often emit extra register-register copies that slow things down.)
Bit-mashing instructions like bitscan forward, reverse and popcount

Finally, we get to the "implement a whole function in asm" part.
Here, yes, it is often a last resort in an all-out search for
performance. In my experience, functions that benefit the most are
ones where you just can't get the compiler to emit efficient code
because of some hidden knowledge you have, but can't quite tell it.
Otherwise, these days compilers do a pretty good job, and mindlessly
converting C into assembly is unlikely to create much of a speed-up.

Agreed.
--
Flash Gordon
.

Quantcast