Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!epiwrl!epimass!jbuck
From: jbuck@epimass.UUCP (Joe Buck)
Newsgroups: comp.lang.c
Subject: Re: Portable C vs Efficient C or "Cost of Portability"
Message-ID: <1103@epimass.UUCP>
Date: Sun, 26-Apr-87 16:14:26 EDT
Article-I.D.: epimass.1103
Posted: Sun Apr 26 16:14:26 1987
Date-Received: Sun, 26-Apr-87 23:49:17 EDT
References: <213@pyuxe.UUCP> <636@edge.UUCP> <1316@frog.UUCP> <658@edge.UUCP> <1017@ubc-cs.UUCP> <682@edge.UUCP>
Reply-To: jbuck@epimass.UUCP (Joe Buck)
Organization: Entropic Processing, Inc., Cupertino, CA
Lines: 129

In article <682@edge.UUCP> doug@edge.UUCP (Doug Pardee) writes:
>> I'm certainly not a C zealot, but I can't think of *any* application for
>> which C is a poor choice as a language but assembler is a good one.
>
>Well, let's see.  There are some obvious ones, like real-time life-support
>or safety-monitor applications in which it is absolutely necessary to show
>that in the worst case, the response time will be less than x microseconds.
>(This requires not only assembler language, but also relatively primitive
>CPUs and system designs in which the hardware performance can be determined
>exactly, none of this "depends on the percent of cache hits" stuff allowed.)

Granted.  But then you can't use any modern CPU chip, without
overspecifying CPU power a good bit.

>Less obviously, almost anything having to do with character handling.  Most
>CPUs provide hardware instructions for string copies, compares, and searches.
>C provides no statements which could be compiled into these instructions.

Not granted.  Library functions (strcpy, strcmp, etc) should be
written in assembler to best exploit a particular machine's
capabilities (though one can start the project with a C version).
ANSI C will provide mechanisms to compile this in-line.

>Also, anything that has to do with direct hardware manipulation (like device
>drivers).  On the 68000, for instance, the assembler programmer has the
>MOVEP instruction which allows easy writing of multiple bytes to I/O
>devices.  In C, there's no statement that can do this, so you end up with
>  *(char *)0x12345 = (val >> 8) & 0xFF;
>  *(char *)0x12347 = val & 0xFF;

The 68000's notion of "odd bytes only" or "even bytes only" for device
registers is ugly enough so you have to use assembler.  Gag me!

>Another reason for writing device drivers in assembler is to have absolute
>control over when and how the I/O locations are referenced.  Trying to
>program an ordinary 2681/68681 DUART, for instance, you have to have a certain
>amount of time pass between references.  And certain locations are off-limits;
>you don't want the C compiler generating a >1 byte fetch which accidently
>includes a no-no byte (this is with memory-mapped I/O, of course).

This is an argument for using a mixture of assembly and C.

>And even with the decent optimizing compilers, code size in C is awful.  See
>the discussion in comp.sys.amiga about how to get "hello, world" down from
>8K to 1K!  In assembler, it'd be maybe 50 bytes.

Wrong, since "printf" is written in assembler in most cases.  I keep
seeing this absolutely bogus argument.  The right solution is 

	puts ("Hello, world\n");

which should be about 50 bytes.  You should know better, Doug. printf
contains code to handle every possible %n.m{s,d,c,f,o,x} that might
appear.  That's a lot of stuff to drag around when you don't need it.

>I hope that isn't how it sounded.  What I was trying to say is that C
>programming is a rather attractive profession to someone who isn't really a
>professional-level programmer, and it is just too easy for them to get into.
>The existence of these people drags down the average quality of C code, and
>puts heavy strain on salaries and working conditions for *all* C programmers.

Oh, crap.  I don't think the quality of most assembly code I've run
into is really all that high.  As Sturgeon said, 90% of everything is
crap.  A good programmer will produce n lines of working C just as
fast as n lines of working assembler.  A good programmer will also
recognize that the best solution to some of the problems you pose is
a mixture of assembler and C, and the more C there is, the fewer bugs
the code will have.

>Don't get lost, I'm getting to a subtle point (I hope).  Because there are
>so many C programmers, who will work for low pay under less-than-thrilling
>conditions, many employers insist that their employees write in C.

Because C can be produced faster, is easier to debug, and, yes, can
be done by more people; because C can be written to be portable when
done by a knowledgeable programmer, many employers specify C.

>Subpoint #1: This really is the employer's right. Subpoint #2: This guarantees
>that they can get cheap replacements with little effort.  Subpoint #3: The
>employers don't really have to insist too hard, because the "programmers" they
>hire don't know anything but C anyway.  Subpoint #4: This is a great
>situation for those not-too-competent programmers; even though the pay is low
>and there's a lot of competition for the jobs, things are a lot worse in the
>burger-flipping business.

I find that people who know too much about the machines they are
working on produce worse C!  Why?  For example, picture a 68000 C
with 2-byte ints and 4-byte longs.  I had a guy who insisted on using
longs instead of pointers.  Well, it works, and it's the right size,
right?  People who are too close to the hardware often tend to build
unstructured monstrosities, which, while often fast and small, remind
one of the old joke: if architects built buildings the way
programmers built programs, the first woodpecker that came along
would destroy civilization.

Because of the freedom C gives you, it can be a dangerous language
for a poor programmer.  Really good C programmers are a rare breed
and deserve good pay.

>Major Point: what is good for the employer and for the not-so-capable
>programmers is not necessarily in the best interests of genuinely capable
>programmers.

I'm not convinced that the people you're calling "genuinely capable
programmers" are the same group I would use the term for.  How about
"overspecialized has-beens"?  For many problems, people-time is more
expensive, and software maintenance more costly, than some waste in
CPU time and memory space.  So the C program is twice as big and half
as fast as the best possible assembly program.  It can be produced in
one-third the time, and it's cheaper to maintain, and it's more
likely to be correct.  And, if done correctly, it can be moved to
different hardware quickly and cheaply.  If anything, C gives you too
much freedom and a more restrictive language might be still better.  

>Corollaries: it is also not necessarily in the product's best interests.  It
>is also not necessarily in the customers' best interests (for those cases when
>the code is part of a product).

Certain applications have to be fast and small, and times have to be
predicted exactly.  For these applications, use assembler.

>  "If all you have is a hammer, everything looks like a nail."

While you say you use C sometimes, I think assembler is your hammer.
I think the group of problems where assembler is appropriate is a
good deal smaller than you think it is.
-- 
- Joe Buck    {hplabs,ihnp4,sun,ames}!oliveb!epimass!jbuck
	      seismo!epiwrl!epimass!jbuck