billw@navajo.STANFORD.EDU (William E. Westfield) (12/31/86)
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
shebs@utah-cs.UUCP (Stanley Shebs) (12/31/86)
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