Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!nbires!hao!noao!mcdsun!sunburn!gtx!edge!doug
From: doug@edge.UUCP (Doug Pardee)
Newsgroups: comp.lang.c
Subject: Re: Portable C vs Efficient C or "Cost of Portability"
Message-ID: <682@edge.UUCP>
Date: Fri, 24-Apr-87 18:22:22 EDT
Article-I.D.: edge.682
Posted: Fri Apr 24 18:22:22 1987
Date-Received: Sun, 26-Apr-87 22:30:41 EDT
References: <213@pyuxe.UUCP> <636@edge.UUCP> <1316@frog.UUCP> <658@edge.UUCP> <1017@ubc-cs.UUCP>
Organization: Edge Computer Corporation, Scottsdale, AZ
Lines: 85

I see no reason to repeat my previous postings on the use of assembler for
some non-portable applications.  But I would like to expand on a couple of
points:

> 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.)

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.

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;

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).

> Of course, that does not mean that a particular C compiler will give code of
> adequate efficiency.

This is the more important consideration.  There's a lot of talk about what
compilers *could* do in optimization.  And somehow that's gotten translated
into the mistaken belief that all of this wonderful optimization is really
happening, or will happen soon.

The truth is that most C compilers are based on PCC, and produce absolutely
terrible code.  Any programmer who has only PCC available should *not* believe
any of the jive about C code being efficient.

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.

> Doug goes on to remark that C programmers just switched from Basic.

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.

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.
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.

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.

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).

> please don't attack C because it isn't assembler.

Perhaps that's how it sounded, but 'tain't so.  I do program in C, a lot of
the time.  Been doing it for years.  I'm not attacking C, I'm attacking the
thoughtless use of C in applications where it doesn't belong.  C is a fine
language for a lot of things, but some people seem to be operating on the
age old principle,
  "If all you have is a hammer, everything looks like a nail."

-- Doug Pardee -- Edge Computer Corp. -- Scottsdale, Arizona