Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!columbia!rutgers!princeton!allegra!ulysses!mhuxt!ihnp4!inuxc!pur-ee!j.cc.purdue.edu!k.cc.purdue.edu!l.cc.purdue.edu!cik
From: cik@l.cc.purdue.edu.UUCP
Newsgroups: comp.lang.misc
Subject: Re:HLL vs. assembler
Message-ID: <487@l.cc.purdue.edu>
Date: Thu, 1-Jan-87 07:20:42 EST
Article-I.D.: l.487
Posted: Thu Jan  1 07:20:42 1987
Date-Received: Sun, 4-Jan-87 21:38:19 EST
Reply-To: cik@l.cc.purdue.edu (Herman Rubin)
Distribution: world
Organization: Purdue University Statistics Department
Lines: 41


It is true that the increased speed of hardware has made souroutine
calls usually faster, but relatively much slower.  On the CYBER 205,
I estimate that a subroutine call will cost 50-100 instructions.
It is also true that subroutine calls do a lot, but, especially in
a program to be included in a library, do I want to call the fire
department to extinguish a match?  Even a transfer on many machines
is now more expensive than most instructions.  When the gurus first
started touting HLL's, conditional transfers were cheaper that any
arithmetic operations.

Another problem with HLL's is that machine-trivial operations may be
difficult to produce.  Overflows, extractions, violating type restrictions,
using condition codes on minis and micros, etc., are simple and efficient.

The question of space saving has also been raised.  It is true that
usually a HLL source program is shorter than an assembler source program.
However, this is mostly due to the horribly designed assembler syntax,
and a well-designed assembler should not run over 1.5 times as much
space as an equivalent HLL program, and may be very much shorter, since
lengthy HLL constructions, such as structures, unions, and many declarations,
can be omitted.  The addition of macro capabilities can even do more.
The object programs will almost always be shorter, and the space taken
at run time even more so.  An INLINE function may be shorter than the
subroutine call; the C subroutine calls abs and fabs should always be
inline, among many others.

Another problem I have encountered, and the only satisfactory solution I
have found is to modify the object file, is the inclusion of tables in a
program.  In several cases, the tables are computer generated, and there
is no reason to read the tables in any way other than to verify their
correctness.  I have run into this problem many times, recently with
513 number tables.  

-- 
(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