Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sdd.hp.com!news.cs.indiana.edu!news.nd.edu!mentor.cc.purdue.edu!pop.stat.purdue.edu!hrubin
From: hrubin@pop.stat.purdue.edu (Herman Rubin)
Newsgroups: comp.arch
Subject: Re: instruction stack
Message-ID: <7184@mentor.cc.purdue.edu>
Date: 1 Mar 91 13:10:43 GMT
References: <1991Feb26.112611.808@ulkyvx.bitnet>
Sender: news@mentor.cc.purdue.edu
Lines: 38

In article <1991Feb26.112611.808@ulkyvx.bitnet>, rmbult01@ulkyvx.bitnet (Robert M. Bultman) writes:
> The CDC 6600, 7600, STAR 100, and IBM 360/195 made use of an
> instruction stack.  The implementation varied, but generally they were
> used to speed up operation of loops.  If a backwards branch referenced
> an instruction contained within the instruction stack, the instruction
> was obtained from the instruction stack rather than main store.  This
> allowed the CPU<->Memory path to be used for data access rather than
> instruction fetch.  I have several questions regarding this:

Forward references were also speeded up.  In the 6600/7600, this was not as
common as on some of the others, but some of them brought in a forward stack
as well upon reaching boundaries.

>     1) Do any recent (> 1985) machines use this, or has this been
>        obviated by the use of cache?

I believe the ETA10 has this, and I do not know which others.  On some
machines, this is referred to as an instruction cache; the uses of
"cache" and "stack" here are essentially the same.  Presumably, one
could even have different levels of this.

>     2) Was this mechanism software controllable, or was it a
>        hardware-only mechanism?  (The reference (see below) regarding
>        this indicated it was hardware only using an address comparison
>        to determine if the backwards jump fell within the limit of the
>        instruction stack.  This sounds like a very small i-cache but
>        is contained within the CPU.)

As far as I know, this was hardware only.  I do not know of any instructions
on these machines, and some others, which would allow software control.

>     3) Would such a mechanism help RISCs? (Why? Why not?)

Unless memory access is as fast as stack address, of course it would help.
--
Herman Rubin, Dept. of Statistics, Purdue Univ., West Lafayette IN47907-1399
Phone: (317)494-6054
hrubin@l.cc.purdue.edu (Internet, bitnet)   {purdue,pur-ee}!l.cc!hrubin(UUCP)