Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!utgpu!water!watnot!watmath!clyde!cbatt!ihnp4!homxb!houxm!mhuxt!mhuxm!mhuxo!ulysses!allegra!alice!adb
From: adb@alice.UUCP
Newsgroups: comp.arch
Subject: Re: register window machine questions
Message-ID: <6698@alice.uUCp>
Date: Tue, 10-Mar-87 09:58:40 EST
Article-I.D.: alice.6698
Posted: Tue Mar 10 09:58:40 1987
Date-Received: Thu, 12-Mar-87 22:39:30 EST
References: <4376@columbia.UUCP> <7284@boring.mcvax.cwi.nl> <115@tmsoft.UUCP>
Organization: AT&T Bell Laboratories, Murray Hill NJ
Lines: 17
Summary: cacheing stacks around a stack pointer

In article <115@tmsoft.UUCP>, mason@tmsoft.UUCP writes:
> >What I have in mind is a stackish machine, with an intelligent
> >stack cache that will delay writes around the stack pointer
> The problem for really high performance is that: as all the activity takes
> place around the stack pointer it is difficult to get much pipelining in progress.  ...
For the CRISP microprocessor, we avoid the problem associated with stack
pointer writes by designing the architecture so stack pointer writes are
hardly ever done -- only on procedure entry and exit.  The two instructions
that modify the SP are carefully managed so addresses are still calculated
properly, and the stack cache on flushes on procedure entry.
> >One of the advantages of this seems to be that compilers become
> >simpler (no special cases for routines that run out of registers),
> (But the compiler induced bug rate would certainly go down.)
We hope so.

	Alan Berebaum, AT&T-Something,
	..!ihnp4!homxa!adb, ..!research!adb