Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!mnetor!seismo!brl-adm!adm!Leisner.Henr@Xerox.COM From: Leisner.Henr@Xerox.COM (marty) Newsgroups: comp.lang.c Subject: Re: Portable C vs Efficient C or \"Cost of Portability\" Message-ID: <7089@brl-adm.ARPA> Date: Fri, 24-Apr-87 10:57:00 EST Article-I.D.: brl-adm.7089 Posted: Fri Apr 24 10:57:00 1987 Date-Received: Sat, 25-Apr-87 19:18:30 EST Sender: news@brl-adm.ARPA Lines: 33 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