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