From: fjh@mundil.cs.mu.OZ.AU (Fergus James HENDERSON)
Newsgroups: alt.folklore.computers
Subject: Re: The need for an assembler (was: Favorite CPU)
Date: 4 Sep 92 17:02:21 GMT
Organization: Computer Science, University of Melbourne, Australia

lasner@watsun.cc.columbia.edu (Charles Lasner) writes:

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

Although I have been following this thread for quite a while, I apparently
missed the start of it, and I haven't seen any examples posted at all.
Perhaps you could post them again.

(Otherwise I might be forced to agree with the poster who suggested that
perhaps the references to examples were just a smokescreen :-| )

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

I suspect that your claim that "The stuff in question can't be syntactically
expressed in the kind of hll you are talking about" stems from a
misunderstanding of HLLs and compilers, especially when you go on to
show that it *could* be syntactically expressed, as a call to a library
subroutine.

Again, if you repost the examples, then we might be able to judge your
claims on their merits.

>>>(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.

Actually, since computers are in actual fact basically finite state automata,
and since in the abstract sense HLL's are equivalent to Turing Machines,
HLL's are in fact abstractions of *supersets* of what a computer does.
Of course, this means that sometimes the abstraction will break down; the
usual error message in this case is something like "stack overflow" or
"insufficient core" :-)
-- 
Fergus Henderson             fjh@munta.cs.mu.OZ.AU      
This .signature virus is a self-referential statement that is true - but 
you will only be able to consistently believe it if you copy it to your own
.signature file!