Path: utzoo!news-server.csri.toronto.edu!cs.utexas.edu!sun-barr!newstop!sun!amdcad!dvorak.amd.com!nucleus!davec From: davec@nucleus.amd.com (Dave Christie) Newsgroups: comp.arch Subject: Re: register save Message-ID: <1991Mar11.165331.4977@dvorak.amd.com> Date: 11 Mar 91 16:53:31 GMT References: <7403@mentor.cc.purdue.edu> <1991Mar07.014907.11081@kithrup.COM> Sender: usenet@dvorak.amd.com (Usenet News) Reply-To: davec@nucleus.amd.com (Dave Christie) Organization: Advanced Micro Devices, Austin, TX Lines: 47 In article peter@ficc.ferranti.com (Peter da Silva) writes: >> and the resgisters saved are described by the bitmask from 0x1234&0x3. Now, >> what do you do, however, when you call bar, which uses a mask of 0x1230? >> foo does a > >> call bar, 0x3 > >> and the resultant mask is 0, thus no registers are saved, *despite* bar >> trashing some of foo's caller's registers. > >You could solve this by keeping running track of "dirty" registers, which >get set by "call" and cleared by "save". > >Let's see how this works here: > >You have to have "call" or-in the mask to be used, and have "save" clear >the bits of the registered saved. That way any bits left over from foo's >caller would still be set, unless foo has already saved them. > >Looks like it'd work. You could even use established VM techniques to >decide when to save registers, but that's probably overkill. Yes, this does it. In a former life I designed hardware support for a mainframe with VAX style every-thing-but-the-kitchen-sink call/return instructions to do the register save/restores in essentially zero time. The paper that Preston Briggs referred to seems very similar - a little state machine + stack for each register; also a stack for the save masks and maybe some other control state. It had to be transparent to software for backwards compatibility. Fun to design, but fraught with extra bits of complexity due to pipelining, branches, fault tolerance, context switches, etc. In the final analysis, it was hard to justify the complexity and realestate, compared with the cost/performance of, say, R3000 call/return. It was never implemented. In fact, it was one (of several) of the experiences with CISC design that made me a RISC advocate... And added another straw to their CISC camel's back. IMHO, the 29000 stack cache is a much better way (no plug intended) (well, maybe a little...) >-- >Peter da Silva. `-_-' peter@ferranti.com >+1 713 274 5180. 'U` "Have you hugged your wolf today?" --------------- Dave Christie My opinions only.