Xref: utzoo comp.arch:22369 comp.lang.misc:7719
Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!pacific.mps.ohio-state.edu!linac!att!news.cs.indiana.edu!news.nd.edu!mentor.cc.purdue.edu!pop.stat.purdue.edu!hrubin
From: hrubin@pop.stat.purdue.edu (Herman Rubin)
Newsgroups: comp.arch,comp.lang.misc
Subject: Re: Compilers, architecture, efficiency, and HR
Message-ID: <11813@mentor.cc.purdue.edu>
Date: 3 May 91 14:14:33 GMT
References: <1991Apr29.155945.29907@rice.edu> <41279@genrad.UUCP> <282002D1.EA1@tct.com>
Sender: news@mentor.cc.purdue.edu
Followup-To: comp.arch
Lines: 65

In article <282002D1.EA1@tct.com>, chip@tct.com (Chip Salzenberg) writes:
> According to hrubin@pop.stat.purdue.edu (Herman Rubin):
> >Satisfysing my requests would require nothing of the sort.  I see no 
> >reason why I should have to hire a compiler writer for each augmentation.
> 
> You're right, of course.
> 
> Nor can I see a reason why we should endure endless tirades about how
> the all-singing all-dancing Herman Rubin Language Compiler will solve
> the world's problems, when you STILL haven't written ...
> 
>   [wait for it]
> 
>      the SPECIFICATION.
> 
> Give us a spec, and we'll have something to discuss.  Why spend all
> this time yammering about a hypothetical compiler, when that same
> effort expended in spec-writing could produce a REAL IMPLEMENTATION?

I have several times responded to this type of posting in email, and
have not even received clarification of my questions.

1.  I am not quite sure what you mean by a specification.

2.  To the extent that I understand it, I do not think that one
even should be produced.

Now, I do not mean that it is all a mystery.  I will try to clarify the
problem and objectives.  I envision a user as having some things to be
done, which for purposes of discussion we shall call transformations.
There are many ways of producing these transformations by sequences of
operations.  The compiler cannot be expected to know how to do this; the 
user must carefully instruct it by the program.  Now this means that the
program may present the compiler with alternatives to assess for speed,
memory requirements, etc.

For convenience, the arguments of these operations may be typed.  The
collection of types is at the user's disposal.  This allows overloaded
operations.  However, it may be convenient to have a few "standard" types.

Next, these operations may be further decomposed into sequences of other
operations, sequences of machine instructions, etc.  The user should have
control over this.  There may be a default set of operations, but the user
should have essentially free rein over operation symbols, etc.  Again, it
is possible that there will be situations in which altenate translation
sequences should be made available to the compiler.

I have not specified a language, but a frame on which to hang a language.
Unlike the present languages, this frame does not declare certain operations,
such as + - * / & | ~ ^ ** << >> as THE primitive operators, but allows free
extension of the notion of primitive operator.  If a user wishes to use [) as
an operator symbol, there is no bar to this.  If the user wishes to deliberately
override types, likewise.  If the user wishes to define an operation in a maner
using assembler instructions, transfer on overflow, etc., which cannot be
conveniently done with the present "portable" primitives, go ahead.

I have given examples of this.  To some extent, this was done by the AUGMENT
preprocessor to handle multiple precision arithmetic, but this was limited.
This essentially unrestricted translation phase can be combined with whatever
optimization techniques are to be further implemented.  Even here, allowing
the compiler to lay out alternatives to the user and get input can be desirable.
-- 
Herman Rubin, Dept. of Statistics, Purdue Univ., West Lafayette IN47907-1399
Phone: (317)494-6054
hrubin@l.cc.purdue.edu (Internet, bitnet)   {purdue,pur-ee}!l.cc!hrubin(UUCP)