[net.lang] Assembly VS HOL: Having it both ways

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