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