Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!wuarchive!udel!haven.umd.edu!ncifcrf!lhc!adm!smoke!gwyn
From: gwyn@smoke.brl.mil (Doug Gwyn)
Newsgroups: comp.sys.apple2
Subject: Re: CRCs
Message-ID: <15953@smoke.brl.mil>
Date: 23 Apr 91 20:51:31 GMT
References: <13688@ucrmath.ucr.edu> <15915@smoke.brl.mil> <13769@ucrmath.ucr.edu>
Organization: U.S. Army Ballistic Research Laboratory, APG, MD.
Lines: 60

In article <13769@ucrmath.ucr.edu> rhyde@gibson.ucr.edu (randy hyde) writes:
>You keep claiming it isn't fair to compare an assembly language code routine
>to a C routine when the assembly language code doesn't support C linkages.
>Why would someone writing their code in assembly language use such linkages?
>Of course if you were writing a single routine to link into a big C program.
>But I'm talking about someone writing the entire program in C.

The reason is that you need to impose identical constraints ("requirements")
on the task if you want to have a fair comparison.  The C-generated machine
code that I posted shows that at least some C compilers generate fairly
decent instruction sequences for the algorithm itself.  The timing for the
CRC-16 example was dominated by "overhead" time, not by the CRC-16
computation.  For a fair comparison of different implementations of the
SAME task, the functional interface should be the same.  In fact, were I to
have to use the example CRC-16 C code in an actual application, it wouldn't
take me long to identify the bottleneck caused by making a function call
per every two bytes of checksummed data, and change the code to eliminate
that overhead; in effect, when writing the assembly code you had already
performed a similar linkage optimization by passing data in registers.

Almost all the assembly code I can lay my hands on around here is expected
to be used from a higher-level language, because we don't agree with the
notion that to gain any benefit from use of assembler it is necessary to
do EVERYthing in assembler.  For large projects, that would be sheer folly.
Consequently, it is reasonable to expect that much code in assembler will
have to meet the constraints imposed by HLL interprocedural linkage and
other run-time conventions.  If you were to tackle an entire project in
assembler, then you avoid any specific HLL's run-time conventions, but you
have to do similar bookkeeping somehow.  I can attest from experience that
it is harder to get those details right when using assembly language; more
of the responsibility for bookkeeping must be assumed by the programmer
(speaking generally) when using assembler -- which is one of the big
reasons for using a higher-level language.

>... as the program gets larger, so does the speed difference.

This directly contradicts the observations of professional software
engineers dating as far back as the 1960s.  Indeed, it is taken as a
virtual axiom these days that most of the execution time in spent in
a minority of the code.  Because most applications have one or more
such identifiable bottlenecks in a small portion of the code (often
in just a few lines of the HLL source code), even an infinite speedup
in the majority of the code would have little effect on the overall
application speed.  Indeed, use of assembly language to speed up
genuine bottlenecks is one of the few uses of assembly language that
I would consider legitimate -- but only after the bottleneck has been
clearly identified and only if other solutions are insufficient.  (Jon
Bentley has written some nice books on the subject of improving code
efficiency.)

>I can't comment on which is worse, a poorly written C program or a
>poorly written assembly language program.  They're both really bad.  

That's true, but even well-written assembly code is unlikely to be of
much value for porting purposes, while some truly horrible C code has
been ported all around the place.

Your point about coding quality is well taken -- no matter what
programming language is used, it is possible to produce a neat,
maintainable job or an ugly unmaintainable mess.