Re: Caller/Callee saved Registers

pardo@cs.washington.edu (David Keppel)
Mon, 28 Mar 1994 23:32:10 GMT

          From comp.compilers

Related articles
[19 earlier articles]
Re: Caller/Callee saved Registers law@fast.cs.utah.edu (1994-03-26)
Re: Caller/Callee saved Registers hbaker@netcom.com (1994-03-26)
Re: Caller/Callee saved Registers hbaker@netcom.com (1994-03-26)
Re: Caller/Callee saved Registers hbaker@netcom.com (1994-03-26)
Re: Caller/Callee saved Registers anton@mips.complang.tuwien.ac.at (1994-03-28)
Re: Caller/Callee saved Registers zsh@cs.princeton.edu (1994-03-27)
Re: Caller/Callee saved Registers pardo@cs.washington.edu (1994-03-28)
Re: Caller/Callee saved Registers pardo@cs.washington.edu (1994-03-29)
Re: Caller/Callee saved Registers bart@cs.uoregon.edu (1994-03-29)
Re: Caller/Callee saved Registers hbaker@netcom.com (1994-03-29)
Re: Caller/Callee saved Registers hbaker@netcom.com (1994-03-29)
Re: Caller/Callee saved Registers pardo@cs.washington.edu (1994-03-31)
Re: Caller/Callee saved Registers conway@munta.cs.mu.OZ.AU (1994-04-02)
[4 later articles]
| List of all articles for this month |

Newsgroups: comp.compilers
From: pardo@cs.washington.edu (David Keppel)
Keywords: registers, optimize
Organization: Computer Science & Engineering, U. of Washington, Seattle
References: 94-03-054 94-03-131
Date: Mon, 28 Mar 1994 23:32:10 GMT

bart@cs.uoregon.edu (Barton Christopher Massey) writes:
>I know of no C-based systems whose calling conventions
>support multiple entry points to a procedure ...


The KSR-1 compiler/runtime system requires that every procedure have (or
at least beahve `as if' it has) two normal entry points: one for when the
caller expects a return value that's a structure and one for when the
caller expects a non-struct return value (or none at all). In addition,
non-leaf procedures must have (or behave `as if' they had) one minor entry
point for each call site they contain.


The struct return entry is first, at offset 0 from the procedure start.
It is typically a branch to the "real" function entry code (the second
delay slot instruction comes from the first instruction of the second
entry point but the first entry squashes it to avoid side effects).


The non-struct-return entry is second at an offset 16 from the procedure
start. It typically sets a flag (to indicate non-struct invocation, for
use at return) and falls through to the "real" function entry code. Even
routines that do not return structures support (`as if') the dual-entry
behavior.




In addition, each call site is organized like (each line is actually an
8-byte instruction pair):


call <target>
delay-slot-1
delay-slot-2
nargs-instruction


The return pc is set to be the address of the `call' instruction. The
callee can make use of the built-in `nargs' routine to determine how many
(words of) arguments the caller passed. The `nargs' builtin is
implemented in the callee as:


jump 24(return pc) ! jump to caller's nargs-instruction
jump L1 ! jump back to callee -- in delay slot !!
        L1:


That is, the callee branches to the `nargs-instruction' of the caller, but
the callee branch is followed by a delay slot instruction that branches
back to the callee, so only a single caller instruction is executed. That
instruction is typically something like `mov N,%reg', to set N, the number
of (words of) caller args. Note that this makes it hard to implement
`nargs' in a threads package that supports varargs, since there must be an
`nargs-instruction' for each possible value of `N'.




Whether you think these `nargs-instruction' bits qualify as entry points
probably depends on how you squint at the code. The struct/nonstruct
entreis, though, certainly qualify. (As an aside, all calls are also done
using an indirect call through a descriptor, but it's implemented as an
indirect pointer, not as a stub code fragment.)


Disclaimer: I'm doing this all from memory andn probably got some bits
wrong.


;-D on ( Caller-slave registers ) Pardo
--


Post a followup to this message

Return to the comp.compilers page.
Search the comp.compilers archives again.