Well, I wouldn't want to interfere with what you're doing,
but here are a few advice from hard-earned experience.
The advantages of Assembly
Assembly can express very low-level things:
- you can access machine-dependent registers and I/O.
- you can control the exact behavior of code
in critical sections that might involve hardware or I/O lock-ups
- you can break the conventions of your usual compiler,
which might allow some optimizations
(like temporarily breaking rules about GC, threading, etc).
- get access to unusual programming modes of your processor
(e.g. 16 bit code for startup or BIOS interface on Intel PCs)
- you can build interfaces between code fragments
using incompatible conventions
(e.g. produced by different compilers,
or separated by a low-level interface).
- you can produce reasonably fast code for tight loops
to cope with a bad non-optimizing compiler
(but then, there are free optimizing compilers available!)
- you can produce hand-optimized code
that's perfectly tuned for your particular hardware setup,
though not to anyone else's.
- you can write some code for your new language's
optimizing compiler
(that's something few will ever do, and even they, not often).
The disadvantages of Assembly
Assembly is a very low-level language
(the lowest above hand-coding the binary instruction patterns).
This means
- it's long and tedious to write initially,
- it's very bug-prone,
- your bugs will be very difficult to chase,
- it's very difficult to understand and modify,
i.e. to maintain.
- the result is very non-portable to other architectures,
existing or future,
- your code will be optimized only for a certain implementation
of a same architecture:
for instance, among Intel-compatible platforms,
each CPU design and variation
(bus width, cache speed and size,
presence of FPU, MMX or other extensions)
implies potentially completely different optimization techniques.
CPU designs already include
Intel 386, 486, Pentium, PPro; Cyrix 5x86, 6x86; AMD K5;
and new designs keep appearing.
- your code might also be unportable accross different
OS platforms on the same architecture, by lack of proper tools
(well, NASM seems to work or be workable on all intel platforms).
- you spend more time on a few details,
and can't focus on small and large algorithmic design,
that are known to bring the largest part of the speed up.
e.g. you might build very fast
list manipulation primitives in assembly;
only a hash table would have sped up your program much more;
or, in another context, a binary tree;
or some structure distributed over a cluster of CPUs
- a small change in algorithmic design might completely
invalidate all your existing assembly code.
So that either you're ready (and able) to rewrite it all,
or you're tied to a particular algorithmic design
Assessment
All in all, you might find that
though using assembly is sometimes needed,
and might even be useful in a few cases where it is not,
you'll want to:
- minimize the use of assembly code,
- encapsulate this code in well-defined interfaces
- have your assembly code automatically generated
from patterns expressed in a higher-level language
than assembly (from ``macros'' to a high-level language)
- have automatic tools translate these programs
into assembly code
- have this code be optimized if possible
- All of the above, i.e. write an optimizing compiler back-end.
Even in cases when Assembly is needed (e.g. OS development),
you'll find that not so much of it is,
and that the above principles hold.
See the sources for Linux (the OS) about it:
as few assembly as needed,
resulting in a fast, reliable, portable, maintainable OS.
Even a successful game like DOOM was massively written in C,
with a tiny part only being written in assembly for speed up.
Languages with optimizing compilers
For instance, languages like
ObjectiveCAML, SML, CommonLISP, Scheme, ADA, Pascal, C, C++,
all have free optimizing compilers
that'll optimize the bulk of your programs,
and often do better than hand-coded assembly even for tight loops,
while allowing you to focus on higher-level details,
and without forbidding you to grab
a few percent of extra performance
once you've reached a stable design.
Of course, there are also commercial optimizing compilers
for most of these languages, too!
Some languages have compilers that produce C code,
which can be further optimized by a C compiler.
LISP, Scheme, Perl, and many other
are suches.
Speed is fairly good.
General procedure to speed your code up
As for speeding code up,
you should do it only for parts of a program
that a profiling tool has consistently identified
as being a performance bottleneck.
Hence, if you identify some code portion as being too slow, you should
- first try to use a better algorithm;
- then try to compile it instead of interpreting it;
- then try to enable optimization from your compiler;
- then give the compiler hints about how to optimize
(typing information in LISP; register usage with GCC;
lots of options in most compilers, etc).
- then possibly fallback to assembly programming
Finally, before you end up writing assembly,
you should inspect generated code,
to check that the problem really is with bad code generation,
as this might really not be the case:
compiler-generated code might be better than what you'd have written,
particularly on modern pipelined architectures!
Slow parts of a program might be intrinsically so.
Perhaps a completely different approach to the problem might help, then.
Inspecting compiler-generated code
There are many reasons to inspect compiler-generated assembly code.
Here are what you'll do with such code:
- check whether generated code
can be obviously enhanced with hand-coded assembly
- when that's the case,
start from generated code and modify it
instead of starting from scratch
- more generally, use generated code as stubs to modify,
which at least gets right the way
your assembly routines interface to the external world
- track down bugs in your compiler (hopefully rarer)
The standard way to have assembly code be generated
is to invoke your compiler with the -S flag.
This works with most Unix compilers,
including the GNU C Compiler (GCC), but YMMV.
As for GCC, it will produce more understandable assembly code with
the -fverbose-asm command-line option.
Of course, if you want to get good assembly code,
don't forget your usual optimization options and hints!