Path: utzoo!attcan!uunet!mcsun!unido!rwthinf!strange!krischan From: krischan@strange.informatik.rwth-aachen.de (Christian Engel) Newsgroups: comp.os.os9 Subject: Re: Passing parameters by registers is bad use?!?!? Keywords: C compiler, parameter passing Message-ID: <3574@rwthinf.UUCP> Date: 9 Oct 90 14:59:37 GMT References: <2820@cernvax.UUCP> <3117@mcrware.UUCP> <3552@rwthinf.UUCP> <2823@cernvax.UUCP> <3555@rwthinf.UUCP> Sender: news@rwthinf.UUCP Reply-To: krischan@strange.UUCP (Christian Engel) Organization: Informatik RWTH Aachen Lines: 160 Hi! Some more discussion for the chance of cache faults: In article <3552@rwthinf.UUCP> I write: >In article <2820@cernvax.UUCP> rbt@cernvax.UUCP (roberto divia) writes: >>2) bigger is the data area used by the code is and easier is to have a >> cache miss (this in case of processors with data caches). > >Now, that's too high for me. Why should the chance of cache miss increase >in passing parameters via stack? The first two parameters need >space in the stack frame of the called function anyway. That means >there is no difference! The only difference is, that passing parameters >via stack moves them into the stack frame *before* entering the called >function (done by the caller) and passing parameters via registers d0/d1 >moves them into the stack frame after entering the called function >(done by the callee). In article <3555@rwthinf.UUCP> I write: >In article <2823@cernvax.UUCP> rbt@cernvax.UUCP (roberto divia) writes: >>Simply because they will HAVE to be store in the data cache (this is done >>during the PUSH), removing other lines from the cache itself, lines that >>will have to be reloaded in case of new references. The data cache works >>normally as function of the "region" of the data used by the program. Stack >>references will exit from this region, increasing the number of cache >>misses...-- > >Again: You need the same amount of stack storage area in either models. >In any case except for parameters of storage class register space in >the stack frame of the called function is required for the parameters. >I think it makes no difference wether the parameters are moved to the stack >before entering the function or afterwards. The code executed in the >meantime is only the bsr and the link instructions. If you get a >cache miss in one model you will get it in the other, too, don't you? Now some more aspects: Compare the stack frame for both models passing parameters by stack and passing parameters by registers: ---------------------------------------------------------------------- Model of stack frame if passing all parameters by *stack*: high | | |-----------------| | parameters | \ pushed by caller | 1, 2, ... in | | | reverse order | | |-----------------| | pushed by bsr | return address | | |-----------------| > locally accessed by the function / | old link reg. | | | |-----------------| | built by link < | space | | | | for local | | \ | variables | / |-----------------| / | registers saved | | | to give space | by movem < | for local | | | register | \ | variables | |-----------------| <--- Top of stack low | | ---------------------------------------------------------------------- Model of stack frame if passing parameters 1 and 2 via *registers* D0/D1: high | | |-----------------| | parameters | \ pushed by caller | 3, 4, ... in | | | reverse order | | |-----------------| | pushed by bsr | return address | | |-----------------| | / | old link reg. | | | |-----------------| | built by link < | space | | | | for local | > locally accessed by the function \ | variables | | |-----------------| | / | registers saved | | | | to give space | | | | for local | | by movem < | register | | | | variables | | | |-----------------| | \ | parameters 1, 2 | / |-----------------| <--- Top of stack low | | ---------------------------------------------------------------------- The propabilty of a cache fault will raise if the area of the accessed memory grows. If you compare both models you will see that the accessed area will be larger for the model of passing all register via stack if and only if there are one or two parameters and there are no local register variables. Looks like this: ---------------------------------------------------------------------- Model of stack frame if passing all parameters by *stack*: high | | |-----------------| | parameters | \ pushed by caller | 1, 2 in | | | reverse order | | |-----------------| | pushed by bsr | return address | | |-----------------| > locally accessed by the function / | old link reg. | | | |-----------------| | built by link < | space | | | | for local | | \ | variables | / |-----------------| <--- Top of stack low | | ---------------------------------------------------------------------- Model of stack frame if passing parameters 1 and 2 via *registers* D0/D1: high | | |-----------------| pushed by bsr | return address | |-----------------| / | old link reg. | | |-----------------| built by link < | space | \ | | for local | | \ | variables | > locally accessed by the function |-----------------| | by movem | parameters 1, 2 | / |-----------------| <--- Top of stack low | | ---------------------------------------------------------------------- The difference of the sizes accessed is 8 Bytes. Now we can discuss how high is the propability that this happens. I think the probability for passing exactly one or two parameters is very high. That gives an advantage for passing by registers. But this advantage decreases with any registers to be freed for local register variables. It is lost with two register variables and becomes a disadvantage with more than two. This propability depends on your programming style (how often do you use local variables of storage class register?) and the compiler used (does it execute an optimization changing local variables from storage class automatic to register?). Krischan -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- krischan@informatik.rwth-aachen.de *** mcvax!unido!rwthinf!strange!krischan Christian Engel, Lehrstuhl fuer Informatik I, RWTH Aachen Ahornstr. 55, D-5100 Aachen, W. Germany