From: lasner@watsun.cc.columbia.edu (Charles Lasner)
Newsgroups: alt.folklore.computers
Subject: Re: The need for an assembler (was: Favorite CPU)
Date: 1 Sep 92 21:48:53 GMT
Reply-To: lasner@watsun.cc.columbia.edu (Charles Lasner)
Organization: Columbia University

In article <9224500.8027@mulga.cs.mu.OZ.AU> fjh@munta.cs.mu.OZ.AU (Fergus James HENDERSON) writes:
>lasner@watsun.cc.columbia.edu (Charles Lasner) writes:
>
>>In article <9224103.2761@mulga.cs.mu.OZ.AU> fjh@cs.mu.OZ.AU (Fergus Henderson) writes:
>>>I maintain that ANY given assembler "trick" CAN be built into a compiler.
>>>If it is seriously worthwhile, then it WILL be.
>>
>>[Lasner disagrees...]
>>We sufficiently discussed items that don't translate
>>into hll as currently implemented everywhere.
>
>The fact that something has not been implemented does not mean that it
>is in principle impossible.

To borrow from Snopes in a.f.u, that's what *you* say.  I sincerely doubt that
languages are going in the direction to implement the assembly-specific stuff
we have been discussing.  It's often difficult to understand in assembler,
and isn't syntactically "palatable" to anything near-enough like languages
that exist today.  In fact, the whole thrust of today's "modern" languages
is in that fairy-tale abstraction direction: let's define a semi-verbose
way of describing *some* of the features of the way computers really work.
Thus, where do you expect this magic implementation to come from.

>
>>Thus, you deny what has been universally agreed upon.
>
>Your definition of "universally" must be different to mine :-)
>

I think you find yourself in a mojority of one situation.  You aren't aware
of the implications of the algorithms discussed, which I admit has been in
a slightly "familiar" and short-hand way between knowledgable assembler
people familiar with these methods, but the whole point is that the major
producers of hll don't deal with these issues.  All of the people who
either don't know or don't care about these issues are against you on this.
In order for your argument to hold up, they would have to agree with me
that the current compilers are "flawed" in this manner, and moreover see
some form of "game plan" that includes incorporating them.  HLL's have been
around for quite a number of years; the direction of them is going *away* from
the methods discussed.

>The fact is that a compiler can emit whatever assembler code it likes.
>People HAVE written compilers that identify certain particular constructs
>and then emit carefully hand-crafted assembler that does the same thing.
>It IS possible, at least in principle, for a compiler to emit exactly the
>same code as anything a human could write.

The stuff in question can't be syntactically expressed in the kind of hll
you are talking about.  If a hll largely consists of library calls to
closed functions or is an interpreter, then the details of some of the code
supporting the closed functions may indeed contain these features.  Hopefully
more than a few do; I personally know of some.  But, these features are 
off-limits at the hll level, and of course the code in question is written
in assembler.

Perhaps, someone in the future will figure out a syntax for some of this,
but not in the current trendy world we have now.  beyond that remote hope,
you would then have to hope that what got implemented resembled the original
assembler, or a much greater danger: what if machines are created that are
so emasculated that all they have are the wimpy instruction sequences only
equivalent to the hll structure of today!  Then the assembler techniques
won't translate at all, and the shallow subset of what's possible *today*
won't exist, and of course neither would any of my arguments. :-).

>
>>(The relative merit of the untranslatables is
>>another issue, but not their existence.)

>
>There are no absolute untranslatables.
>There *are* "tricks" that your current compiler is not smart enough to
>use, but for every trick you can think of, I can write a compiler that
>is smart enough to use it.

Good trick, since the syntax to express it may be missing in the language.
Remember, hll's are abstractions of *subsets* of what a computer does.

cjl