Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10 5/3/83; site bbncca.ARPA Path: utzoo!linus!bbncca!bray From: bray@bbncca.ARPA (James Bray) Newsgroups: net.arch Subject: Re: (Re: x 3) risc registers and cache Message-ID: <416@bbncca.ARPA> Date: Thu, 22-Dec-83 19:43:58 EST Article-I.D.: bbncca.416 Posted: Thu Dec 22 19:43:58 1983 Date-Received: Fri, 23-Dec-83 01:06:08 EST References: <1939@fortune.UUCP> <153@intelca.UUCP> Organization: Bolt, Beranek and Newman, Cambridge, Ma. Lines: 24 What I think it is pretty clear at this point one really wants, when making a machine to execute modern (stack-based) languages, is not registers but rather economies of addressing and arrangement of storage based on a hierarchical model in which it is assumed that the top-of-stack will be the most heavily referenced cell, and that cells deeper in the stack will be referenced in inverse proportion to their distance from TOS. From this model emerges the realization that at some depth in the stack the frequency of reference will be the same as for a random location, and that for some depth of stack N such that N <= this drop-off point, it is proper to optimize machine addressing and access time for this portion of the stack. This is completely in line with part of the the fundamental RISC philosophy outlined in the paper describing the IBM 801, which is that it makes sense to speed up the 10% of instructions executed 90% of the time, even at the expense of slowing down or eliminating some or all of the other 90%. I thought I was quite clever for thinking this up until I discovered that the designers of the Symbolics 3600 and probably some other machines had already done it in hardware. Note that the idea of a RISC assumes no particular storage model: the IBM 801 seems to have 32 very conventional-looking registers. This model, however, does seem to be philosophically compatible if it can be implemented without slowing down the basic emulation-loop too much. Registers are a hack that compilers would love to live without if provided with a fast, economically addressable stack. --Jim Bray (decvax!bbncca!jbray),