Path: utzoo!attcan!uunet!zephyr.ens.tek.com!uw-beaver!mit-eddie!rutgers!cs.utexas.edu!tut.cis.ohio-state.edu!purdue!mentor.cc.purdue.edu!l.cc.purdue.edu!cik
From: cik@l.cc.purdue.edu (Herman Rubin)
Newsgroups: comp.arch
Subject: Re: Compilers taking advantage of architectural enhancements
Message-ID: <2661@l.cc.purdue.edu>
Date: 21 Oct 90 13:02:35 GMT
References: <1990Oct9> <3300194@m.cs.uiuc.edu> <11922@ganymede.inmos.co.uk> <339@fjcp60.GOV>
Organization: Purdue University Statistics Department
Lines: 47

In article <339@fjcp60.GOV>, golds@fjcnet.GOV (Rich Goldschmidt) writes:
> In article <2649@l.cc.purdue.edu>, cik@l.cc.purdue.edu (Herman Rubin) writes:
> > If we limit languages and compilers to what is taught to CS graduate
> > students now, we can only freeze them at the present sorry state.  There
  
> I was not trying to suggest that compiler technology should be frozen.  I
> thought I was suggesting an area of research for compiler designers.
> The point of automating compiler generation is not necessarily to produce
> a final product, but to couple compiler development more tightly with
> chip development, and avoid the kind of situation we see with the i860
> where there is no compiler which can really take advantage of the chip
> long after its introduction.  By using an automatically generated compiler
> early in the chip design process, it might be clear very quickly that certain 
> features will require substantial effort to take advantage of, and either
> plan for that effort far in advance, or decide that it might be more 
> productive to consider alternate designs.  I would think this would be a
> very fertile area for research by chip manufacturers, since the sooner they
> can get a compiler available the better off they are in selling their chips.
> They will still need experts to enhance automaticaly generated compilers,
> but at least they have a first cut more quickly, and get better feedback
> early in the design process.  I am surprised by the lack of interest in this 
> concept among this group, but maybe I don't know enough to see the flaws in 
> my suggestions.

This is still letting compilers	drive the architecture.  There are many useful
constructs not in the present languages or architectures.  Instead of trying to
limit the architecture to what an automaton can use, we should be trying to see
what those who think differently can find ways to use.

The emphasis in this group should be on architectures which can do things
efficiently, whether or not there are languages or compilers which can make
use of the power ot those architectures.  I doubt if we will have in the
foreseeable future a language or compiler which can consider what human
ingenuity is capable of.  This does not mean that the constructs in the
languages (NOT the compilers) may not suggest architecture enhancements,
but that should not be the only source of such suggestions.  But to deliberately
restruct an architecture to what a language provides is at best an insult to
all thinking people.  To limit it to what can be handled by an automated
compiler is, IMHO, criminal.

Remember that a comuter program is a fast sub-imbecile.  This includes 
compilers.  An interactive compiler MAY allow the use of human ingenuity,
but even this may be difficult.
-- 
Herman Rubin, Dept. of Statistics, Purdue Univ., West Lafayette IN47907
Phone: (317)494-6054
hrubin@l.cc.purdue.edu (Internet, bitnet)	{purdue,pur-ee}!l.cc!cik(UUCP)