cik@l.cc.purdue.edu (Herman Rubin) (12/19/86)
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.edurentsch@unc.UUCP (Tim Rentsch) (12/29/86)
In article <483@l.cc.purdue.edu> cik@l.cc.purdue.edu (Herman Rubin) writes: > Also, one should realize that, as opposed to 30 years ago, transfers > and subroutine calls have become expensive. Now, wait a minute. That statement is misleading if not downright false. In the first place, subroutine calls (and transfers) have gotten faster over the years. So if they have become expensive, they are only *relatively* expensive, compared to other operations which may have gotten faster at a larger rate. So even if this is the only consideration (it isn't, see the following), subroutine calls have not "become expensive", they have instead gotten *cheaper*, only at a (perhaps) slower rate than some other things. In the second place, work done on pipelining and instruction look-ahead (yes, done in the last 30 years) has given a great deal of attention of subroutine calls and branches, precisely because they were expensive to begin with. (There are some very clever schemes for branching -- inlcuding one machine where an unconditional branch takes ZERO time. Zero anythings is never "expensive".) Since they were expensive to begin with, and since they had more attention paid to them, one would think they are cheaper now. (Studies comparing machines of thirty years ago to machines of today are welcome.) And, in the third place, subroutine calls do *more* now than they did thirty years ago. (Early machines did not even have subroutine call instructions, remember.) Comparing a Pascal subroutine call with a Fortran subroutine call is like comparing apples and oranges. The increased semantic power of the call must be considered before such a call can be said to be "more expensive". cheers, txr