Path: utzoo!utgpu!news-server.csri.toronto.edu!rutgers!cbmvax!snark!eric
From: eric@snark.thyrsus.com (Eric S. Raymond)
Newsgroups: comp.lang.misc
Subject: Re: Re: Aggressive optimization
Message-ID: <1YLLn1#0Szy8F4Zp5Fb8v0RP50kql0M=eric@snark.thyrsus.com>
Date: 3 Nov 90 08:52:06 GMT
References: <2301@wn1.sci.kun.nl> <8960020@hpfcso.HP.COM> <3674@stl.stc.co.uk>
Lines: 40

In <3674@stl.stc.co.uk> Tom Thomson wrote:
> one to one translation?  back in the 60s we used to talk about 
> the Fortran assembler;  even earlier we had machines like Deuce 
> where the assembler would fix the placement of instructions for
> you to minimise drum latencies, which was maybe one-to-one still
> but very much against the spirit of your proposed restriction on
> assemblers.

I don't think your examples do much to challenge the previous poster's
contention; they're all neolithic-era or older! These `optimizing'
assemblers were all designed before the idea of HLLs had matured, in
response to a *very* different set of tradeoffs than drives today's
relatively hard distinction between HLLs and assemblers.

I think it's a little too restrictive to characterize assemblers as one-to-one
instruction translators. The essential functional difference is that HLL code
is *opaque*; you can't look at it and write the corresponding machine code
sequence without knowing global information such as name-to-stack-offset
mappings. Assembler code, on the other hand, is transparent; you can look
at it and see where all the bits will fall.

"But wait!", I hear you say. "What about...macroassemblers?". Yes, they're
a bit of a hybrid. But hey, when's the last you heard of anybody *using*
one? One of the effects of maturing compiler technology for HLLs (and
especially of the spread of C) has been to `purify' assemblers; from the
point of view of a modern language designer, MACRO-10 was an overengineered
wrong turn, like a Zeppelin with stained-glass windows.

The pcc design made an important evolutionary step by actually generating
assembler source rather than object records. This completed the separation
of function -- the HLL for abstraction handling, the assembler for bashing
instruction bits into place.

I think there are all kinds of good engineering reasons to believe this
separation of function between HLL and assembler will be a stable feature
of future development-environment design for compiled languages. From that
modern point of view, the gentleman making the `one-to-one' claim was
correct in concept if not in detail.
-- 
      Eric S. Raymond = eric@snark.thyrsus.com  (mad mastermind of TMN-Netnews)