Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 (Tek) 9/28/84 based on 9/17/84; site mako.UUCP
Path: utzoo!watmath!clyde!burl!ulysses!allegra!mit-eddie!genrad!decvax!tektronix!orca!mako!jans
From: jans@mako.UUCP (Jan Steinman)
Newsgroups: net.lang,net.arch
Subject: Re: Assembly VS HOL: Having it both ways
Message-ID: <757@mako.UUCP>
Date: Thu, 9-May-85 15:55:57 EDT
Article-I.D.: mako.757
Posted: Thu May  9 15:55:57 1985
Date-Received: Mon, 13-May-85 15:57:27 EDT
References: <1220@topaz.ARPA> <511@terak.UUCP> <1440@amdahl.UUCP>
Reply-To: jans@mako.UUCP (Jan Steinman)
Organization: Tektronix, Wilsonville OR
Lines: 24
Xref: watmath net.lang:1571 net.arch:1170
Summary: 

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