Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!husc6!panda!genrad!decvax!decwrl!labrea!navajo!billw
From: billw@navajo.STANFORD.EDU (William E. Westfield)
Newsgroups: comp.lang.misc
Subject: Assembly vs HLL
Message-ID: <1256@navajo.STANFORD.EDU>
Date: Tue, 30-Dec-86 20:25:49 EST
Article-I.D.: navajo.1256
Posted: Tue Dec 30 20:25:49 1986
Date-Received: Wed, 31-Dec-86 03:38:10 EST
Organization: Stanford University
Lines: 57


OK, maybe things aren't quite as bad as I thought.  Some versions of
Portable Standard Lisp support direct manipulation of the stack,
C++ has inline procedures (and runs under most unixes), and the MESA
environment appears to have a really good compiler that does lots
of optimizations (and probably runs on several Xerox processors, or
was that one of the languages that was never allowed out the door?)

Note that a lot of things that can be done reasonably efficiently
in a particular high level language may not be efficient in some
otehr language (Im still trying to to prevent this debate from
talking too much about a particular HLL or assembler.  Here is
another example this time involving bit arrays.

The DEC20, and probably also the VAX, and perhaps the 68020 and Vnn
have special instructions for dealing with partial words (bit fields).
On the DEC20 at least, this means you can allocate an arrays of bits,
and then indivually fetch and store any bit therein in 3 instructions:

	move AC,[point 1,ARRAY,0]		;base of the array
	adjbp AC,(COUNT)			;adjust by desired bit
	ldb/dpb AC,AC				;load or store bit.

(not all of these are very fast instructions, mind you, but it is
 probably faster than other instruction sequences doing the same thing)

Now, I can believe that a reasonably advanced pascal compiler could
produce this code from something using "packed array[0..n] of boolean".
But the equivilent C code (or fortran or whatever) would contain
shifts and divides and all sorts of things that the original idea
would be rather obscured, and I doubt whether any optimizer could
do as well.  most often people just code byte arrays instead (taking
up 8 times the space, but being fundementally faster, i guess)
It seems rather silly to start with an idea, munge it into the
constraints of the language, and then have the optimizer need to
unmunge things back to the original idea, and this seems to
happen a lot.

Someone else mentioned that ASM programmers should work on writing
better compilers.  This is an idea, but code generation seems to
be rather an obscure art - in my UG compiler class we spent most
of the semester learning how to parse things in various ways, and
a total of about a week on how you might generate hypothetical
3 operand instructiosn from the parse data.  Sigh.  Part of the
problem is a top-down vs bottom up view of code - its much easier
to generate obscure fast code for an algorithm than to backtrack
from (unoptomized) compiler output back to the original intent.
Also, in most cases, compilers ARE adequately fast, and any needed
speed can usually be gotten by writing only parts in a HLL.  Time
spent hacking the compiler is of less use than time spent defining
a new language, but that doesn't work because there are too many
languages already.  Remember, Im not arguing that ASM should be
used over HLLs, Im just arguing that HLL is frequently NOT nearly
as fast as ASM code 9which many people seem to believe).  Most of
the time it doesn't matter.

BillW