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