Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!ut-sally!utah-cs!shebs
From: shebs@utah-cs.UUCP (Stanley Shebs)
Newsgroups: comp.lang.misc
Subject: Re: Assembly vs HLL
Message-ID: <4130@utah-cs.UUCP>
Date: Wed, 31-Dec-86 11:35:38 EST
Article-I.D.: utah-cs.4130
Posted: Wed Dec 31 11:35:38 1986
Date-Received: Wed, 31-Dec-86 20:48:31 EST
References: <1256@navajo.STANFORD.EDU>
Reply-To: shebs@utah-cs.UUCP (Stanley Shebs)
Organization: PASS Research Group
Lines: 40

In article <1256@navajo.STANFORD.EDU> billw@navajo.STANFORD.EDU (William E. Westfield) writes:

>[detailed example involving bit manipulation]
>
>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.

This is a very powerful argument against low-level languages.
It *is* silly to take a reasonable abstraction (bit fields), encrypt
it into shifts and masks etc, then expect a compiler to reconstruct
the original idea.  Vectorizing Fortran compilers for parallel processors
lose in the same way.  You're better off using languages that support
the abstractions directly.  That's why for instance Common Lisp has
hundreds of fairly abstract functions (including both bit arrays and
bit field operations).  The downside of this approach is that it makes
a lot of work for the implementor, who may get tired and do things the
easy way, perhaps implementing bit field operations with division or
something.  The poor user ends up being puzzled as to why a program
is 5 times slower in the Foo Inc. implementation than it is in Obscure's
implementation on the exact same hardware.

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

Sad but true.  There's been a suggestion kicking around our dept
about a two-quarter compiler class, in which the first quarter is
formal languages + parsers, and the second quarter starts with an
abstract syntax tree and concentrates on code generation/optimization.
Lisp hackers would skip the first quarter and only take the second :-).
It's curious that even though almost all the languages faculty at Utah
are into Lisp and/or functional programming, the compiler class is still
taught in the traditional way...

>BillW