🚀 go-pugleaf

In pcg@rupert.cs.aber.ac.uk (Piercarlo Grandi) writes
many things.  Among them, he responds to my comment that
>   CPU's outrun memory.  They have been for years, and memory
>   isn't catching up. Hence the development of caches, multi-level caches, 
>   wide data busses, and large register sets.
>
>Von Neumann's bottleneck? Who said bottleneck? The guy from Thinking
>Technologies down the hall? :->

Nobody I know knows about Thinking Technologies.  Who are they?
My initial guess was that you meant Danny Hillis at Thinking Machines.
A smart man, but his machines are a little out my league.

Further, naming the problem doesn't make it go away.
It reality that memory costs money and that fast memory costs
more money.  Using multiple-levels in your hierarchy is an engineering
tradeoff that works.

>On general purpose architectures and codes, of
>course. If you can otherwise predict access patterns, "registers" win
>(can I say "vector codes"?).

Sure.  But the predictability and reuses arises due to loops
and arrays, things that appear in many time-consuming chunks of code.
Not every program fits, but many do, including programs written
in Fortran, C, Pascal, Ada, ...

>There is an uncertain tradeoff between generality and reliability and
>complexity of hardware vs. software here. A particularly difficult
>issue. My own rule is that complexity that is not supported by very big
>sure advantages is to be regarded with the utmost suspicion, whether it
>manifests itself as number of intructions, address modes, registers,
>optimizers, and so on...

I have sympathy with this position.  I think most people outside the 
government do.  However, I also recognize that some of these 
complexities, mastered, achieve performance.

In particular, I think optimization is a Good Thing.  
It allows me to specify my programs in less time and with less complexity.  
It allows me to offload tedious, error-prone tasks onto the computer.

To make an optimizer effective though, we need a large supply of registers.
Without an adequate register set, our simplifying seperation of concerns
(front end vs. optimization vs. instruction selection vs. register allocation)
breaks down.  Perhaps this doesn't appear simple!  It isn't entirely, 
and hasn't always been recognized or possible.  I think it's one of the
under-emphasized results of the whole 801/PL.8 project.

Hoare, in "Hints on Programming Language Design", wanted a language

	in which a simple straightforward "non-pessimising"
	compiler will produce straightforward object programs
	of acceptable compactness and efficiency...

I think this is a tremendous suggestion.  Further, I believe it's
what Grandi has been pressing for.  However, leaving out the
optimization doesn't achieve these desired result.  My optimizer
(not the world's best or worst) produces remarkably straighforward
code.  I think it's what most people would want to see out of their
compiler.  (I'm not including the agressive source-to-source transformations
I've talked about before.)

I think it's just more difficult to produce "straightforward object programs
of acceptable compactness and efficiency" than most people recognize.
I believe it requires a fair amount of analysis and transformation
(that is, optimization and register allocation).
--
Preston Briggs				looking for the great leap forward
preston@titan.rice.edu