dgary@ecsvax.UUCP (D Gary Grady) (05/06/85)
Can't recall if anyone has pointed this out before, but Burroughs large systems (as of five or ten years ago when I was working with Burroughs gear) has no assembly language. Instead they used a dialect of Algol that permitted complete control of the generated code. It might be noted that advantage of assembly language is only in its power to control exactly what the object format will be (with the possible exception of some assemblers for Intel 80x8x processors, which still tend to surprise me with their inventive code productions). If a high-level language can be given the ability to specify exactly what object code will be produced, we can have it both ways. It might even be possible to do this in a somewhat "machine independent" fashion; that is, in a way that isolates the machine-specific instructions. A simple way of doing that is the #asm directive found in some C compilers. Burroughs medium systems Algol (BPL) allowed the use of assembler mnemonics as statement modifiers; an assignment statement might be followed by a :MW to force a move word to be generated (going from memory, here). Obviously, for this to work some degrading of optimization might be necessary. It might also be desirable to have a sort of conversation between the compiler and the programmer during the compile. Critical sections of code could be marked by the programmer and the compiler could say, "Here's what I've generated for this; what changes do you want me to make?" Sorry this is so vague; my real point is that rather than having to choose between two unsatisfactory options, it would be nice to have a third way to go that preserved the undeniable advantages of high-level languages without preventing us from producing code as tight as we might ever want. -- D Gary Grady Duke U Comp Center, Durham, NC 27706 (919) 684-3695 USENET: {seismo,decvax,ihnp4,akgua,etc.}!mcnc!ecsvax!dgary
sambo@ukma.UUCP (Inventor of micro-S) (05/09/85)
In article <1163@ecsvax.UUCP>, dgary@ecsvax.UUCP (D Gary Grady) writes: > It might be noted that advantage of assembly language is only in its > power to control exactly what the object format will be (with the > possible exception of some assemblers for Intel 80x8x processors, which > still tend to surprise me with their inventive code productions). What are some of these inventive code productions?
jans@mako.UUCP (Jan Steinman) (05/09/85)
I can see two strong uses for assembly code. The first, (and most obvious to HOL programmers) is to re-code critical procedures in assembly code. This is the case that the "optimizing compiler" camp gets upset over, and is also the case that dgary@ecsvax.UUCP (D Gary Grady) addresses: >... If a high-level language can be given the ability to specify exactly >what object code will be produced, we can have it both ways... A second, more controversial aproach, is one used when the mechanics of a language itself is responsible for unacceptable inefficencies. Assembly code is then used for the whole project, using highly unconventional techniques, in order to significantly improve time or space performance. A friend of mine wrote an 8080 emulator that used the NS32000 stack pointer for the emulated 8080 program counter, I am writing a large (~64k) interpreter that does not contain a single subroutine call, etc, etc. Current compilers certainly can be improved, and I am all in favor of producing and using optimizing compilers. But changing the paradigm of a given language's machine usage is beyond the realm of any mechanical optimization of which I am aware. -- :::::: Jan Steinman Box 1000, MS 61-161 (w)503/685-2843 :::::: :::::: tektronix!tekecs!jans Wilsonville, OR 97070 (h)503/657-7703 ::::::