Path: utzoo!utgpu!news-server.csri.toronto.edu!hub.toronto.edu!thomson
Newsgroups: comp.arch
From: thomson@hub.toronto.edu (Brian Thomson)
Subject: Re: What the compiler won't do you for you
Message-ID: <1991Mar1.094249.27890@jarvis.csri.toronto.edu>
Organization: University of Toronto
References: <8787@exodus.Eng.Sun.COM> <24280:Feb2802:55:4991@kramden.acf.nyu.edu> <8808@exodus.Eng.Sun.COM> <1991Feb28.181948.26958@rice.edu>
Date: 1 Mar 91 14:42:49 GMT
Lines: 24

In article <1991Feb28.181948.26958@rice.edu> preston@ariel.rice.edu (Preston Briggs) writes:
>	The 3rd is much harder again.  Recognizing all the ways
>	I might code a particularly complex function as being equivalent
>	to some bizzarre instruction is quite difficult -- probably
>	impossible.

All the ways, yes.  But many of the ways, perhaps not.
I seem to remember running across a reference, about 10 years ago
(that's when I saw it, not necessarily when it was published),
that dealt with recognizing common sequences of operations in APL
and compiling them into particularly efficient code.
I think they called it "recognition of programming idioms" or something
of the sort.  Does this ring a bell with anyone?

>	It's also wrong-headed, for many reasons.  Chase pointed out
>	that there's only a small payoff. 

I think that, in the APL case, the payoff was somewhat higher because
it sometimes encourages the use of powerful yet expensive operations
to accomplish relatively simple tasks.

-- 
		    Brian Thomson,	    CSRI Univ. of Toronto
		    utcsri!uthub!thomson, thomson@hub.toronto.edu