assembler v. HLL 
Author Message
 assembler v. HLL

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



Wed, 19 May 1993 16:02:00 GMT  
 assembler v. HLL

Quote:

>    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



Wed, 19 May 1993 18:08:00 GMT  
 
 [ 2 post ] 

 Relevant Pages 

1. HLL vs. assembler

2. Simplest HLL APL in character mode

3. Mainframe HLL Migration

4. HLL Forth

5. HLL Forth

6. assembly programming prefereable to HLL programming ?

7. HLL-to-C compilation

8. Mainframe HLL Migration

9. Best HLL/Compiler for CPU Performance

10. References on first-class functions in HLL ?

11. need modifiable source for clean interpreter written in an HLL

12. Assembly vs HLL debate

 

 
Powered by phpBB® Forum Software