Many algorithms, for example quicksort or walking thru binary trees or inserting
into balanced trees like AVL trees etc., need to be written as recursive
functions or procedures. If you want to do this in ASSEMBLER, you have to do all
the housekeeping etc. to get the many incarnations of variables of the recursive
invocations of that functions. Or, you need arrays to simulate the recursion
stack etc., which means storage management. Anyway, you have to deal with it.
This management has to be done by the ASSEMBLER programmer.
In my experience, the ASSEMBLER coder will simply not end up with such
solutions, because the effort for this kind of management is to high. Instead,
he takes simpler algorithms to do the same thing and hopes that the speed of
ASSEMBLER will help him - but that's wrong, IMHO.
So, as others already said, a mixture of, for example, C and ASSEMBLER, and a
well-trained programmer who knows both languages well, is best.
Am 09.04.2011 17:14, schrieb K.W.:
> Cheating is always encouraged :-), but I think that the point was that
> neither programmer had such a routine "in his toolbox". The C
> programmer will find something that is easily reused, the assembler
> guy probably won't.
> Will the C routine run as fast as hand-crafted assembler written by a
> great programmer? Probably not. But a mixed Assembler/C programmer
> will have more time to design and analyze the system and then rewrite
> the performance critical sections in assembler if necessary (and
> assuming that the C compiler isn't just as good).
> PS> Sure, its heresy to criticize assembler on this list. I simply
> believe that most assembler programmers should consider learning/using
> C since there are tools (Metal-C, Dignus, etc) that I believe will
> allow them to develop systems in mixed C/HLASM that will be better
> than assembler alone. Besides, if you want to branch out and work on
> z Linux (or other Linuxen), then knowing C well will be a big plus.