Article View: comp.lang.misc
Article #1905Re: Re: Aggressive optimization
From: Eric S. Raymond
Date: Sat, 03 Nov 1990 08:52
Date: Sat, 03 Nov 1990 08:52
40 lines
2662 bytes
2662 bytes
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)
Technical Details
Message-ID:
<1YLLn1#0Szy8F4Zp5Fb8v0RP50kql0M=eric@snark.thyrsus.com>Path:
arc1-ca.pugleaf.net!utzoo!utgpu!news-server.csri.toronto.edu!rutgers!cbmvax!snark!ericReferences:
<2301@wn1.sci.kun.nl> <8960020@hpfcso.HP.COM> <3674@stl.stc.co.uk>Show Full Headers
Complete Article Headers
Path: arc1-ca.pugleaf.net!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