Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!utgpu!water!watnot!watmath!clyde!rutgers!seismo!lll-lcc!ames!amdcad!bcase From: bcase@amdcad.UUCP Newsgroups: comp.arch Subject: Re: RISC register windows Message-ID: <14984@amdcad.UUCP> Date: Thu, 26-Feb-87 12:48:45 EST Article-I.D.: amdcad.14984 Posted: Thu Feb 26 12:48:45 1987 Date-Received: Sat, 28-Feb-87 05:05:17 EST References: <1881@homxc.UUCP> <898@moscom.UUCP> <476@mntgfx.MENTOR.COM> Reply-To: bcase@amdcad.UUCP (Brian Case) Organization: Advanced Micro Devices, Sunnyvale, California Lines: 65 Keywords: performace, cache In article <161@astroatc.UUCP> johnw@astroatc.UUCP (John F. Wardale) writes: >Its clear to me from the questions, that many people don't understand RISC. Well, I am confident in *my* understanding. >RISC stands for Reduced Istruction Set Computer. True, this is true. But the choice of the RISC acronym was unfortunate. Reducing the number of instructions is incidental. I know that the Berkeley people emphasized this point in the beginning, but I think they (Patterson and Katevenis (yes, I know he is out of the country)) would no longer emphasize this aspect of simple machines. >Features common to RISC machines: >[a list of features] Sigh, RISC machines have whatever features are necessary to achieve an instruction rate of close to one per cycle and achieve a good compiler interface. >The Purpose of Register Windows was to remove the need for a cache. As a >student project, a real cache design was deemed too hard. In practice, I >think the Sun/3's and similar machines are proving that windows are not >the "only-true-way" to get good performace. Who ever said that windows were the only true way to get good performance? >This 6/10/6 division of register is arbitrary, but is kept fixed to insure No, not arbitrary. The amount allocated (in this case 16 regs) must be a power of two. >maximum speed. To make it dynamic, would require a size-register >(effectively nargs() value) probably *IN* the window (otherwize it would >not be possible to unwind the call-stack). Well, you can use dynamic links too. (This makes the protocol for variable sized windows more efficient.) >Lets build a *FAST* machine (I-cache, and DATA-cache) with >windows, and a memory system that's wide enough to fill a full window of >registers in one (memory access + split-transfer) time unit. Now what Wow. That's a wide bus, but I like the idea! Bandwidth or bust! >happens when you want to run a new process??? The state you must save is >not just your current window, but your *WHOLE* stack of windows! Windows >are great for running benchmarks, but are not so good for doing context >switching. Anyone know how Pyramid solved this??? How many users (vi, >csh, compiles, etc.) does it take to bring a Pyramid to its knees?? I worked at Pyramid, my thesis details a machine with variable sized windows, and I have build a simple machine with variable size windows (er, activation records that is). Windows are good for running benchmarks *and* real programs. Variable sized windows are just better. You are right, the entire active portion of the register file must be swapped on a full context switch. However, you are completely ignoring the fact that swapping the register file is only a part, a small part, of the work that must be done to perform a context switch. The number of users needed to bring a Pyramid to its knees is not correlated to the fact that it has register windows. To be sure, however, a real-time machine might be better off without windows (latency vs. throughput). Context switch overhead is mittigated by variable sized windows: at least the registers you are swpping are holding useful data. With fixed size windows, there is a high probability that some of the registers you are swapping are not being used. A smaller register file allowing variable sized windows achieves the performance of a larger register file with fixed sized windows. bcase --------- Are you watching this space?