Path: utzoo!utgpu!jarvis.csri.toronto.edu!cs.utexas.edu!uunet!mcsun!hp4nl!kunivv1!ge From: ge@kunivv1.sci.kun.nl (Ge' Weijers) Newsgroups: comp.sys.m88k Subject: Re: Register Allocation (was Re: Info about 88open & standards) Message-ID: <541@kunivv1.sci.kun.nl> Date: 29 Nov 89 12:14:57 GMT References: <1989Nov16.212149.9770@paris.ics.uci.edu> <100050002@hpcuhc.HP.COM> Organization: University of Nijmegen, The Netherlands. Lines: 43 thomas@uplog.se (Thomas Hameenaho) writes: >I have an idea that perhaps could be a bit of both worlds: What about having >the caller supply a mask of live registers to the callee, ie. registers that >must not be clobbered to the callee? This mask should be ANDed with a mask of >the registers that the callee clobbers and handed to the equivalent of MOVEM >(68k) or CALLx (VAX). The save/restore should of course be handled by >microcode/hardware to make it fast. >This way there would never be unnecessary saves. Suppose I write a main program that uses all registers. Then your scheme degenerates to a callee-saves scheme. Especially leaf routines do not benefit from your scheme. Even worse, the performance of a program might depend critically on the register number chosen by the optimiser. This makes predicting performance quite hard. And every procedure call gets extra overhead. The VAX CALLS/G instruction does so much often unnecessary work that not using it is a viable option. A compiler I used to work on was faster than PCC only for this reason. (It used a caller saves convention BTW, and register variables were unknown) The same is true for the compiler I'm currently working on. In functional programming languages the procedure call is so common that the performance depends quite critically on the calling convention. I use a pure caller-saves convention, with parameter passing partially in registers. For things like fibonacci numbers and other recursive programs this runs rings around C, Fortran and what have you. (And don't mention the SPARC, because functional programs really exercise register windows to death :-). I think a functional language implementation is better off not using register windows at all, except if global analysis is done to keep the processor from saving and restoring dead register all the time. This is not trivial in recursive cases. Give me a store-multiple-register please?). I suspect the half-half (or perhaps 60-40) convention is one of the best when you don't have global knowledge. If you have global knowledge then you can implement parameter passing using registers, local variables and global variables, whatever suits the problem. Ge' Weijers Ge' Weijers Internet/UUCP: ge@cs.kun.nl Faculty of Mathematics and Computer Science, (uunet.uu.net!cs.kun.nl!ge) University of Nijmegen, Toernooiveld 1 6525 ED Nijmegen, the Netherlands tel. +3180612483 (UTC-2)