It's true that assembly language can be
useful. It can make certain operations faster,
through the use of optimization techniques. It can
make your code smaller and faster, but the
disadvantages of using assembly often outweigh
the merits.
Assembly is good for two things. The first is
for when you need to access hardware. Writing
routines to interact with the hardware can be
easier and cleaner than the equivalent operation
in C. It is not difficult to export the assembly
routines to make them callable from C or some
other language, so you can get the advantage of
having precise control over the hardware without
having to write your entire program in
assembly.
The other thing assembly is good for is
optimizing certain parts of a program. If you have
an extremely time critical routine that is called a
lot, then it makes sense to go through it with a
fine toothed comb and choke every possible cycle
out of it. You have to look at the speed gain and
compare it to the time you spent optimizing the
code. If you spent three hours optimizing a
routine, and you only get a 2 microsecond speed
gain, then you have to call that routine billions
of times to make it worthwhile. In most cases, its
simply not worth the effort. Embedded applications
and DSP are areas where hand optimization might
make a significant difference, but unless you
doing some extreme number crunching on a PC, its
probably not worth it.
Assembly is hard. You can't glance at the code
and know what its doing. It's not at all self
documenting, its not portable, and its difficult
to maintain. Its also easier to make mistakes in
assembly, and harder to fix them. I'm willing to bet
that the time spent writing a routine in assembly
will be much greater than the time spent writing
the equivalent in C.
I was going to argue about the ugliness of the
x86 memory models, but Whizkid points out that
code for Windows 95 can run in protected mode, so
the memory model is flat and writing assembly
becomes not much worse than writing for a RISC
machine. The instruction set is just more complicated.
Whizkid seems to suggest writing entire
programs in assembly, and complains about the
bloated slowness of Windows libraries. It's true
that any Visual Basic program has a load of
runtime stuff following it around, including the
OLE libraries. A C++ program will usually use MFC,
which is difficult to use and has its own bloated
runtime libraries pulling things to a crawl. A C
program will use the Win32 API directly, but so
will any assembly program that doesn't want to
draw it's own interface. So either way you go, you
only gain from using assembly in hard core number
crunching routines that get used a lot. Even in
assembly, you have to rely on the API to provide
an interface, unless you want to write you own
interface library in assembly. If the only thing
your doing is calling the API, you don't get the
advantages of using assembly, but you get all of
the disadvantages. When you write something in
assembly that just calls a lot of API functions,
you get to waste your time setting up the
stack. So instead of one line of C code, you write
10 lines of assembly, just to call a
function. That's just silly.
Bloat doesn't have to come from libraries
either. You can just as easily write big, slow,
inelegant code in assembly as you can in C or any
other language. Part of writing good code is
knowing how to use your tools and libraries
correctly, and in the application of good, solid
design. Sitting down and coding with a vague goal
in mind but no solid design will give you slow and
ugly code, no matter what language you're
using.
It comes down to having the right tool for the
job. If you can hand optimize a routine better
than a modern C or C++ compiler can, then use
assembly and build a library that can be called
from another program. If you want to write a
device driver, use assembly if you want, but C is
about as good and easier to maintain. If you're
writing GUI that relies on a library like GTK+ or
the Windows API, then your better off in C or C++
or whatever your favorite language is. It just
doesn't make sense to do everything in
assembly. If I write a binary tree library in
assembly on an x86, but then I go and buy a Sun
or something, I have to waste enormous amounts of
time converting it. I could write it in C or C++
and just recompile.
Whizkid says he just wants to see information
about how to do it from companies like
Microsoft. Well, if you have the C prototypes for
a library, you can figure out what you need to put
on the stack to call it from assembly. It doesn't
make sense for Microsoft to put any effort into
releasing assembly specific information. They have
development customers who are usually companies
who don't have time to use assembly. They want
fast development time, not fast code, so that's
what Microsoft tries to give them. Corporations
using Microsoft tools like Visual Basic are
usually writing business applications for in house
use that basically consist of storing things in a
database and then generating reports on them. So
that's the customer that Microsoft caters to,
resulting in things like ADO. Hard core computer
science where assembly might be used comes into
play in other problems, and the people solving
those problems look to academia for information,
not to Microsoft.
I think part of Whizkid's argument for assembly
rests on the "coolness" factor. Doing something
just to see if it can be done. That sort of
thing. Sure, I do things like that too, but it
won't fly in industry.
Back in the day, a programmer knew everything
he needed to know. Now, there's so much
information that you have to keep refering to your
reference manuals just to get through a simple
project. Maybe so, but the libaries and OS's of
today give the programmer so much more. You can
accomplish a lot more by making a few libary or system calls
now than you could then. You don't have to write
your own routines to handle input and output any
more. Instead of wasting time with that, you can
solve the problem you want to solve. Time spent
looking up a library call is nothing compared to
writing the function yourself.
Give me assembly or give me death? No, give me
the right tool to get the job done.