[comp.lang.c] Portable C vs Efficient C or \"Cost of Portability\"

Leisner.Henr@Xerox.COM (marty) (04/24/87)

Well, with all the discussion of C vs. Assembler, I'll add some
comments:

I personally have programmed extensively in both C and 8085/8086
assembler.

I far prefer doing anything complicated in C as opposed to assembler.
Assembler is necessary for doing machine level stuff which C can't cope
with (i.e. saving context for interrupt handlers/context switchers).   

If I absolutely must optimize something, I typically write a first cut
in C; then recode in assembler leaving the C code
as comments.  In addition, it is worthwhile to examine the assembler
output of the compiler and assess whether it is producing "reasonable"
code to solve the problem.  A good compiler can produce assembly
language more accurately and much faster than I can.  

My assembler code typically consists of simple conditional/looping
logic; often to control I/O ports.  If anything complicated needs to be
done, I let the C code do the hard work.  It is more maintainable and
makes more sense.  I generally don't like the inport/outport functions
often found on 8080/8086 C compilers -- I use them for rapid
prototyping, but often replace them with meaningful functions (like
read_disk_controller_status() instead of something like inp(0x2f8)).

I've seen my share of "spaghetti assembler".  Without a doubt, a well
constructed C program could accomplish the same ends in a far more
understandable manner.   When I was writing a CP/M bios, I really wished
I could code some of the stuff in C -- not the low level stuff but
enhancements like a disk buffer cache (where to put it is another
problem on an 8 bit machine).

marty  

jfjr@mitre-bedford.arpa (04/27/87)

  I thought I would add my two cents since I have been following
this new group long enough to get into the swing of things.
  
For device drivers, most micro work, if you haven't the time
or ambition for assembler C is probably your best choice. If
you are involved in a project of significant size (upwards of
20k lines) and more than two programmers who are office mates
related and very good friends I wouldn't touch C with a ten
foot pole. For such things the type checking and abstractions
supplied by Pascal or even better are absolutely necessary.
Its the only way to go. No language can be all things to all
programmers. I bet I'll get tons of replies on this..

                                      Jerry Freedman,Jr

manis@ubc-cs.UUCP (04/28/87)

In article <7134@brl-adm.ARPA> jfjr@mitre-bedford.arpa writes:
>... If you are involved in a project of significant size (upwards of
>20k lines) and more than two programmers who are office mates
>related and very good friends I wouldn't touch C with a ten
>foot pole. For such things the type checking and abstractions
>supplied by Pascal or even better are absolutely necessary.

As one of the contributors to this discussion, I should clarify that
I am of course talking about "typed C", i.e., coding practices which
satisfy even extremely fussy compilers (of which pcc is not one). Such
things as required function prototypes (oh, I wish I had a compiler which
implemented them...), fussy pointer checking, etc., are of course essential
for any real project.

In my naivete, I didn't point out that distinction. The real mileage you
get in high-level languages isn't the 10:1 source code reduction (though 
that is of course significant) but the fact that good compilers flag nonsense
rather than letting it through (on the basis that the programmer *knows* 
that this construct generates a Reverse Backscratch on the Whizzbang 4176).

Of course, one could denigrate such fussy compilers on the basis that they
allow sloppy people to move from burger-flopping to programming. However,
fussy compilers don't enforce good design (this I know: I'm in the process
of marking a stack of term projects written in Modula-2), and that is what 
separates the good programmers from the bad ones.

-----
Vincent Manis                {seismo,uw-beaver}!ubc-vision!ubc-cs!manis
Dept. of Computer Science    manis@cs.ubc.cdn
Univ. of British Columbia    manis%ubc.csnet@csnet-relay.arpa  
Vancouver, B.C. V6T 1W5      manis@ubc.csnet
(604) 228-6770 or 228-3061

"Long live the ideals of Marxism-Lennonism! May the thoughts of Groucho
 and John guide us in word, thought, and deed!"