Xref: utzoo comp.arch:22385 comp.lang.misc:7725
Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sdd.hp.com!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,comp.lang.misc
Subject: Re: Compilers, architecture, efficiency, and HR
Summary: Getting closer
Message-ID: <11856@mentor.cc.purdue.edu>
Date: 3 May 91 22:03:41 GMT
References: <1991Apr29.155945.29907@rice.edu <41279@genrad.UUCP> <1991May3.195856.13671@ux1.cso.uiuc.edu>
Sender: news@mentor.cc.purdue.edu
Followup-To: comp.arch
Lines: 76

In article <1991May3.195856.13671@ux1.cso.uiuc.edu>, msp33327@uxa.cso.uiuc.edu (Michael S. Pereckas) writes:
> In <11813@mentor.cc.purdue.edu> hrubin@pop.stat.purdue.edu (Herman Rubin) writes:
 
> >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.
 
> Sounds vaguely (buzzword alert) object oriented to me.  Except that
> you not only don't want to pay the usual performance penalty of OO
> languages, you want a speed boost over plain C or whatever.  And you
> don't want to write any assembly (although another user might)?

I do not mind using machine operations, but I do not like to write the
vague and confusing, and different for different machines, assembler 
symbolism.  On any machine, one of the things I would do is to include
my own notation for the machine operations, and the corresponding translation.

I have no problem whatever in thinking in terms of machine operations where
necessary, and I have no objection to using them.  But we no longer need to
write these operations in a form designed to be easy for the assembler to
parse.

> (I'm assuming that this is a modified C.  If you like Ada better,
> replace `C' with `Ada' in the following text...)
 
> What if you could define new operations
>     example:
 
> 	@ is defined here as some complicated function of two variables
> 	  using either C or assembler	
 
>         later on you get to write stuff like this:
>     x = y @ z
 
> The code for the @ operation is automagically inlined.  
> Appropriate ifdefs would let you include in the source file several
> versions of the @ code, perhaps in portable C and two different
> assembly languages.  

Almost right!  I may wish to define @ in terms of other things defined.  It
may be desirable to use primitives which even mess up coding, such as overflow.

> You (H. Rubin) would like (I think) to be able to write several
> different but equivalent versions in portable C, and have the compiler
> automagically select the one it can produce the best code for.  This
> sounds like it could be hard.  Perhaps you could include some test
> examples, and the compiler could compile each version and benchmark
> it?
 
> Am I getting close?

One of the claims of the posters is that compilers can greatly outdo 
humans.  They can only outdo humans if they can take into account what
the humans can consider.  This they cannot do without being told.

Now how does a compiler operate now?  It parses the code, translates into
its primitive operators, decides how to make things more efficient, which in
some cases requires consideration of alternatives (Simple example: on the
CDC6600, there were three "standard" methods of putting 0 in an X-register.
These used different functional units, and each functional unit could only
do one thing at a time, and the units were used for other purposes.  So the
compiler would decide which alternative to use.), and then optimize the
resulting hardware instruction code.

This means that the programmer must adequately instruct the compiler on the
possible ways to do things if the compiler is to do well.  Automagic selection
is certainly an important part of optimization.
-- 
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)