🚀 go-pugleaf

RetroBBS NetNews Server

Inspired by RockSolid Light RIP Retro Guy

Article View: comp.arch
Article #10505

Re: Compilers, architecture, and efficiency

#10505
From: Herman Rubin
Date: Tue, 30 Apr 1991 01:55
63 lines
3617 bytes
In article <1991Apr29.155945.29907@rice.edu>, preston@ariel.rice.edu (Preston Briggs) writes:
> hrubin@pop.stat.purdue.edu (Herman Rubin) wrote

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

> And I described how it could be done, using Fortran 77 and pretty
> standard optimization (value numbering and peephole optimization).
> 
> hrubin@pop.stat.purdue.edu (Herman Rubin) replies:
> 
> >Any specific instance of this can be added to the compiler's ken, but
> >until it does, the compiler cannot take advantage of it.  The point is
> >that the compiler must be instructed to look for them.
> 
> Yes indeed.  That's the job of the compiler writer.
> If he does a bad job in using the instruction set of the machine,
> you should complain to him.

Is it the compiler writer's job to recognize combinations of expressions in
a language which really represent an operation not contained in that
language?  How do you separate a float into the exponent and the 
significand?  

What is needed for the user to be able to communicate what operations are
wanted.  It is even  necessary to do this in cases in which the language
supports the desired effect in multiple ways.  Looking for the code and
making sure it has no side effects which would make the supposed improvement
more costly is no simple task, but it is easier if the compiler is told what
is wanted, instead of having to guess.

> >The real2int conversion still has to be done on most machines, and also
> >an integerize of real.  But suppose that the machine has integer hardware
> >comparable to floating hardware, and can also handle unnormalized floats.

> Well, we can suppose all sorts of things.  Nevertheless, my solution
> handles your first set of suppositions.  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 thought your original question was posed in an attempt to show that
> many languages don't have the facilities you consider necessary
> to control the machine.  I just tried to show that the effect you
> wanted could be achieved.

What you have shown is that a compiler can, in effect, extend a language
by looking for certain code patterns.  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.

It is also by having these situations laid out in the open that subsequent
language designers, compiler writers, and hardware designers will be likely
to know about them and include them.  No matter how great these are, there
are plenty of "obvious" things which will be missed.


-- 
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)
Technical Details
Message-ID: <11588@mentor.cc.purdue.edu>
Path: arc1-ca.pugleaf.net!utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!sol.ctr.columbia.edu!bronze!news.cs.indiana.edu!news.nd.edu!mentor.cc.purdue.edu!pop.stat.purdue.edu!hrubin
References: <4082@batman.moravian.EDU> <1991Apr28.154603.8003@rice.edu> <1991Apr29.155945.29907@rice.edu>

Show Full Headers
Complete Article Headers
Path: arc1-ca.pugleaf.net!utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!sol.ctr.columbia.edu!bronze!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
Subject: Re: Compilers, architecture, and efficiency
Message-ID: <11588@mentor.cc.purdue.edu>
Date: 30 Apr 91 01:55:25 GMT
References: <4082@batman.moravian.EDU> <1991Apr28.154603.8003@rice.edu> <1991Apr29.155945.29907@rice.edu>
Sender: news@mentor.cc.purdue.edu
Lines: 63