Path: utzoo!censor!geac!torsqnt!news-server.csri.toronto.edu!cs.utexas.edu!wuarchive!mit-eddie!uw-beaver!ubc-cs!alberta!arcsun.arc.ab.ca!arcsun!kenw From: kenw@skyler.calarc.ARC.AB.CA (Ken Wallewein) Newsgroups: comp.arch Subject: Re: more registers for ix86, was: Let's pretend Message-ID: Date: 3 Jan 91 18:38:08 GMT References: <3042@crdos1.crd.ge.COM> <1990Dec26.020034.4131@lpi.liant.com> <5827@labtam.labtam.oz> Sender: nobody@arc.ab.ca (Absolutely Nobody) Organization: Alberta Research Council, Calgary Alberta, Canada Lines: 26 In-Reply-To: scott@labtam.labtam.oz's message of 3 Jan 91 00:02:44 GMT A short while ago I was going to post a message saying "Hey, I know! Virtual registers!" :-). Seriously, though, I remember reading the docs for processor in the Texas Instruments 99/4A. As I recall, it had three registers: a couple for operands, and one pointer register for a "virtual" register set in RAM. Changing that one register's contents gave one a whole or partially different set. The docs claimed (of course) that this was the way of the future, because processor <-> memory bandwidths were increasing (hah :-). It seems to me that, with a good caching scheme, this could work out to being just about as efficient as 'real' registers. On the other hand, I sometimes wonder whether registers aren't actually an optimizing kludge, and that an instruction set which made no explicit reference to registers at all might be more efficient. Speaking of caches, I seem to recall that single-storage-area caches are supposed to be more efficient than caches which have separate areas for different things. But this would have difficulty dealing with addresses which have low hit rates but high impact. One would almost have to have "cache priority". Has this ever been done? /kenw kenw@noah.arc.ab.ca