Stack Machines

[Chuck Guzis]

On 21 Oct 2006 at 13:24, Ray Arachelian wrote:

> On context changes you always have to save all the registers to memory,
> so you'd lose on any interrupt.  

That's the bonehead way of doing things.  For the way it's done 
right, take a look at the S/360 calling sequence--the called routine 
uses the STM instruction to save just the registers that will be used 
by it.

I've worked with 3-address machines with 256 registers of 64 bits.  
If you're working with even a moderately-sized subroutine under those 
circumstances, the entire set of local variables will usually fit in 
the register file  A smart compiler or programmer can even segment 
the variable set out into dynamic and static variables, so the 
smallest part of the register set is saved upon exit.  

The point is, that no matter how one touts the benefits of a cache as 
being able to substitute for a fast register file, it's a false 
claim.  A cache can never have the information about the nature of a 
program's behavior that the programmer or compiler can--it's too far 
removed from the actual program context and must rely on history for 
what belongs in the cache and what doesn't.

I could also make the same claim about virtual memory systems, but 
then I'd be viewed as too much of an anachronism because EVERYBODY 
knows that virtual memory is best, right?
 
> I'm not familiar with that machine.  What's it look like?

It's one of the classics in big-iron architecture and the darling of 
computer-science professors everywhere.  Here's a description:

http://en.wikipedia.org/wiki/Burroughs_B5000

But the fact is that even with attached FORTRAN coprocessors and 
vector boxes, not even a BSP could out-benchmark a CDC Cyber or Cray 
I on a pure computational load.

Cheers,
Chuck