Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!husc6!hao!boulder!sunybcs!rutgers!bellcore!faline!ulysses!mhuxt!ihnp4!homxb!mtuxo!mtune!codas!killer!usl!usl-pc!jpdres10
From: jpdres10@usl-pc.UUCP (Green Eric Lee)
Newsgroups: comp.arch
Subject: Re: register windows
Message-ID: <230@usl-pc.UUCP>
Date: Wed, 4-Nov-87 12:26:57 EST
Article-I.D.: usl-pc.230
Posted: Wed Nov  4 12:26:57 1987
Date-Received: Wed, 11-Nov-87 03:31:51 EST
Organization: Univ. of Southwestern La., Lafayette
Lines: 23
Summary: register windows vs. register stacks vs. Plain Old Registers

Distribution:


I've been following this conversation for some time. I wonder, how
much does the adder in the register path (to add the register stack
pointer to the instruction's desired register) slow things down in the
AMD29000? It might also seem like if you have register windows, you
have the same thing sitting there in the middle of the address path
between instruction latch and register addressing, but one scheme I've
read about is to make your register windows out of shift-registers,
i.e. no adding, as far as the machine is concerned, you just have your
16 registers out there or whatever, and when a procedure call is made,
or a return made, shift the current registers down or up (with some
provisions for stack overflow). And, of course, Plain Old Registers
have no problem at all with something out there in the register
addressing path, except, of course, the decode tree... it seems
offhand that the MIPS approach, with lots of registers and a very
smart compiler capable of allocating them to procedures as needed,
might offer some potential future speed advantages over traditional
(non-shift-register) register windows or AMD's "stack window"
approach, unless some very heavy pipelining is employed.

---
Eric Green  elg@usl.CSNET       from BEYOND nowhere:
{ihnp4,cbosgd}!killer!elg,      P.O. Box 92191, Lafayette, LA 70509
{ut-sally,killer}!usl!elg     "there's someone in my head, but it's not me..."