Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!mnetor!seismo!rutgers!mit-eddie!genrad!decvax!ucbvax!cbatt!osu-eddie!osupyr!hrubin From: hrubin@osupyr.UUCP (Herman Rubin) Newsgroups: comp.lang.c Subject: Re: Portable C vs Efficient C or "Cost of Portability" Message-ID: <226@osupyr.UUCP> Date: Wed, 22-Apr-87 09:24:43 EST Article-I.D.: osupyr.226 Posted: Wed Apr 22 09:24:43 1987 Date-Received: Fri, 24-Apr-87 04:50:34 EST References: <213@pyuxe.UUCP> <636@edge.UUCP> <1316@frog.UUCP> <658@edge.UUCP> <215@gtx.com> Organization: Department of Statistics Lines: 90 Summary: What if the HLL cannot even do a fair job; uou need to know the machine to decide I have found it necessary to include the entire article for the convenience of the reader; I have placed it at the end. I have frequently encountered situations where the operations I wish to use are extremely difficult in the totally inadequate HLL's available. In other situations, the problem is a (frequently vast) choice of algorithms; the programmer who thinks in BASIC or FORTRAN or C cannot begin to appreciate what can be done. I am inclined to doubt that most of them retain the ability to understand what a computer can do if its instruction capability is utilized. I find machine language easy to understand, even easier than the weird constructs of the HLL's. The difficulty of writing good programs is the now unnecessary awkwardness of assembler constructs. If an intelligently designed assembler, or even macro translator, were available, this could be done. Alternatively, if the intelligent and resourceful programmer could define his types, define operations (e.g., define "`\'" to be the "bit clear" operation on most machines, and to inform the compiler that this is a hardware operation with a syntax similar to the other logical operations, or define ">>>" and "<<<" to be double register shifts), use the condition codes instead of the restricted "?" in C (how do you use integer overflow? I want to use it), allow the programmer to force things to be in registers or even short register vectors, etc., we may reach the stage that a HLL may be used for intelligent programming. Learning the op-codes (and their execution times and overlap properties) is not sufficient, but it is necessary. Does learning HLL thinking prevent, and not just inhibit, learning to make a computer do what the user, and not the compiler designer, wants to do? We do not know how to design a good compiler; a flexible "SuperC" may do a fair job. In article <215@gtx.com>, al@gtx.com (0732) writes: > > doug@edge.UUCP (Doug Pardee) writes: > > > consider this: There are 4 basic reasons for writing a particular program > > in C instead of in assembler: > > a) If efficiency is of little consequence -- the program is only going tome > be run once or twice; > > b) If portability is important; > > c) If the programmer is ignorant of assembler; or > > d) If the boss wants "BIC lighter" programmers: cheap, disposable, and > > easily replaceable. > > One important reason not mentioned above is development time. > Unless there are unusual efficiency considerations, The C programmer can > program rings around the assembly language programmer because there > are fewer low-level discriminations to be made. A well-known folk theorem > of computer science says that it takes about as long to write and debug one > line of, say, Fortran or C as one line of assembly language. Since the > assembly language program is considerably longer, it takes longer to write. > > > A C program is no more readable to a C programmer than an assembler program > > is to an assembler programmer. Ditto for maintainability. The issues of > > Readability and Maintainability come back to points (c) and (d) above; in > > other words, whether we're talking about C programmers or assembler > > programmers. > > "Higher-level" languages such as C and Fortran were all designed and > implemented by exceptionally competent ASSEMBLY LANGUAGE PROGRAMMERS > disgusted by the unreadability and unmaintainability of assembly language. > Portability was always a secondary issue. > > > And finally, <<>> all of the above was > > based on "programmers of equal competency". But consider that point (d) > > above virtually guarantees that the ever-increasing pool of marginally > > competent programmers (you know the ones, "I got me a PeeCee and learnt > > meself how to program in Basic and C") will be hired by penny-pinching > > companies to program in C. > > At least the kid with the PC is educable. Spare me from the > hardware retread who *knows* that all there is to programming is learning > the op-codes for the processor. > > > -------------------------------------------------------------- > | Alan Filipski, GTX Corporation, Phoenix, Arizona 85283, USA | > | ihnp4!arizona!sunburn!gtx!al > -------------------------------------------------------------- > > God took seven days to create the world; > an APL programmer could do it in one line. -- Herman Rubin Until mid May: Department of Statistics, Cockins Hall, 1958 Neil Avenue Ohio State University, Columbus OH43210 hrubin@osupyr or cbosgd!osu-eddie!osupyr!hrubin or ts0474@ohstvma.bitnet "Permanent": Department of Statistics, Purdue University, West Lafayette IN47907 hrubin@l.cc.purdue.edu or ihnp4!pur-ee!stat-l!hrubin or hrubin@purccvm.bitnet