Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!sample.eng.ohio-state.edu!purdue!mentor.cc.purdue.edu!pop.stat.purdue.edu!hrubin
From: hrubin@pop.stat.purdue.edu (Herman Rubin)
Newsgroups: comp.arch
Subject: Re: Compilers, architecture, and efficiency
Message-ID: <11609@mentor.cc.purdue.edu>
Date: 30 Apr 91 15:34:48 GMT
References: <1991Apr28.154603.8003@rice.edu> <1991Apr29.155945.29907@rice.edu> <1991Apr30.025904.13028@rice.edu>
Sender: news@mentor.cc.purdue.edu
Lines: 76

In article <1991Apr30.025904.13028@rice.edu>, preston@ariel.rice.edu (Preston Briggs) writes:
> hrubin@pop.stat.purdue.edu (Herman Rubin) writes:

			......................

> >What is needed for the user to be able to communicate what operations are
> >wanted.
> 
> I agree that the user should be able to instruction the computer.
> However, I don't think I want to specify the assembly operations.
> Instead, I want to manipulate numbers, sets, sequences, and objects in a
> somewhat high-level fashion.  Then I want the compiler to make very good
> code out of my specification.

But what if I find Boolean operations useful in dealing with floats, which
I do for certain purposes?  There are other operations which I can use for
useful purposes, but only if they are fast.  You do not know these operations,
and the language community has seen fit to ignore what those who are capable
of versatility can envision.

> >> If you change the machine, you need to change compilers.
> > 
> >This newsgroup is comp.arch.  How are the computer architects to recognize
> >these situations and others?  
> 
> I expect they learn from reading and by experience.
> It seems that one of the major accomplishments of the RISC evolution
> was a recognition that architects and compiler people should talk
> more often than in the past.

But what about getting input from those users who do not find what they
want?  That multiply and add could be easily combined in hardware was known
BC (before computers); it was routine in desk calculatore (now essentially
extinct).  The only reason I can think of that the early computers did not
have this feature is that it would have taken another register to hold the
multiplier.

One of the reasons why, in the late 50s and early 60s, binary was settled on
(there are many others) was that multiplication by powers of 2 was rather
common.  Only a few machines have this very important operation in floating
hardware, and instead have to bring in the multiplier and use the relatively
slow multiplication.  It is true that with pipelined hardware this is not so
much of a problem, but I know of only a few machines which had it before then.

> >What you have shown is that a compiler can, in effect, extend a language
> >by looking for certain code patterns.
> 
> I disagree.  The language (Fortran 77) didn't change when I added my
> optimization.  The compiler translates exactly the same set of
> programs; some programs simply ran slightly faster.
> 
> >  I fail to see that this procedure,
> >which will always be limited by the information given to the compiler
> >writers, and which can also sometimes lead to difficulties, is better
> >than allowing the user to extend the language and pass the information
> >to the compiler in such a way that it can use more of the 
> >machine capabilities.
> 
> The difference is that we (computer science community in general)
> know how to do optimizing compilers.  You pose a much harder problem.

I agree that you know how to do certain types of optimizations.  I suggest
that you make these optimizations available to those who have a more varied
collection of things to optimize.  You (the computer science community) know
how to optimize, but have only a limited knowledge of what it is useful to
optimize.  I do not criticise you for this lack of knowledge, but only for
failing to realize that you should be looking for input on this from others.

We, and I include all of mankind, do not know enough about to design a good
system of communicating between people and computers now.  We can design a
fair one by realizing this and allowing the users to extend the language, and
to communicate to the compiler this extension.
-- 
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)