Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!mnetor!seismo!brl-adm!rutgers!clyde!cuae2!ihnp4!inuxc!pur-ee!j.cc.purdue.edu!k.cc.purdue.edu!l.cc.purdue.edu!cik From: cik@l.cc.purdue.edu (Herman Rubin) Newsgroups: comp.lang.misc Subject: Re: assembler v. HLL Message-ID: <483@l.cc.purdue.edu> Date: Thu, 18-Dec-86 16:02:54 EST Article-I.D.: l.483 Posted: Thu Dec 18 16:02:54 1986 Date-Received: Fri, 19-Dec-86 05:21:11 EST Organization: Purdue University Statistics Department Lines: 60 As a user having great difficulties producing efficient programs, I must reject both alternatives presented. One purpose of any language, operating system, etc., must be to efficiently use the hardware capabilities. I have no difficulty in deciding quickly which machine operations to use, how to use registers, and other "goodies" which I find the HLL's not even to have the vocabulary to describe. The assemblers, on the other hand, have kept the ease of parsing which was necessary 35 years ago, which makes it difficult to write in them. What is needed is a semi-portable "language" or macro system in which at least the usual constructs are easy to write, e. g., I want to write "x = y - z", assuming that is available as a hardware instruction, in that manner, rather than "sub?? a, b, c", where ?? depends on some designer's fancy, and a, b, and c are x, y, z in some order. I may wish to override types, in which case I may have to use, say, "x =.t y - z". I also would like to be able to define macros of the same ilk. A programming tool of this type would have much of the readability, ease of programming, and semi-portability of high level languages, and have the full efficiency of assembler. I have produced programs to produce floating-point numbers in which the major operations are shifts, masks, and conditional transfers on bits--try that in your HLL to get any speed. (C fails on the bit transfers as well as many other points, but is better than the others.) Remember that the guru producing the HLL probably has no idea of what you or I can think of with the hardware. I firmly believe that anyone capable of understanding what a computer does will find it easy to understand machine language if it presented with understanding rather than as a totally disjointed collection of ideographs. Since it is much more functional than the HLL's, I find it easier to learn the machine architectures of several machines (not the assemblers) rather than the conventions of one HLL. A good programmer should know when to use totally different algorithms on different machines. Also, one should realize that, as opposed to 30 years ago, transfers and subroutine calls have become expensive. I have no trouble in directly writing non-structured code which is as easy to follow as any structured HLL code, given the above tools, which I believe would not be too difficult to produce. Also, languages like FORTRAN and C are designed mainly for mathematical purposes. Mathematical notation was not arrived at by fiat; most mathematicians who wish to use the hardware operation "and not" will use the symbol "backslash", which most HLL's will not allow, and similarly for other Boolean operations. Let us produce compilers and languages that make use of the natural powers of computers and of the human mind, instead of stifling both. -- (Usual disclaimer line.) Herman Rubin, Dept. of Statistics, Purdue Univ., West Lafayette IN47907 Phone: (317)494-6054 (decvax,ihnp4,uiucdcs)!pur-ee!stat-l!cik (decwrl,hplabs,ucbvax)!purdue!stat-l!cik hrubin@l.cc.purdue.edu