Path: utzoo!utgpu!jarvis.csri.toronto.edu!cs.utexas.edu!tut.cis.ohio-state.edu!ucbvax!mtxinu!sybase!binky!tim From: tim@binky.sybase.com (Tim Wood) Newsgroups: comp.sys.m88k Subject: Re: Register Allocation (was Re: Info about 88open & standards) Message-ID: <7263@sybase.sybase.com> Date: 29 Nov 89 23:39:22 GMT References: <1989Nov16.212149.9770@paris.ics.uci.edu> <100050002@hpcuhc.HP.COM> <9972@june.cs.washington.edu> Sender: news@sybase.sybase.com Reply-To: tim@binky.UUCP (Tim Wood) Distribution: na Organization: Sybase, Inc. Lines: 37 In article <9972@june.cs.washington.edu> pardo@june.cs.washington.edu (David Keppel) writes: >thomas@uplog.se (Thomas Hameenaho) writes: >>[Idea: caller register mask, callee register mask, save only >> registers indicated by AND of masks.] > >There is a potential problem. It takes extra code to decide whether >or not to save certain registers. The time you spend executing that >code could be spent naively saving registers and you'd come out about >the same. Hmm, seems like it would all be done at compile time. For every procedure call you compile, note which registers are read or written in the calling routine (or, if "-O" is set, try to determine which ones are not live across the call :-). Then, set the bits in the save mask. Compile in the mask value in your "call-with-mask" instruction sequence (hey, what a great idea for a single instruction! :-) Each compiled procedure would have its own mask, a la VAX. > >On the VAX, where it already has save-by-mask microcode, the tme >penalty might be OK. Except, VAX is oriented toward callee-save. Subroutines must have a 2-byte register-save mask up front in order to be called by the "call-subroutine" instructions. >On the RISC-family processors, you'll probably >lose a lot. Is it worth adding save-by-mask hardware? Probaly not. Please substantiate these assertions. > pardo@cs.washington.edu Sybase, Inc. / 6475 Christie Ave. / Emeryville, CA / 94608 415-596-3500 tim@sybase.com {pacbell,pyramid,sun,{uunet,ucbvax}!mtxinu}!sybase!tim This message is solely my personal opinion. It is not a representation of Sybase, Inc. OK.