Olin Lathrop <olin_piclist <at> embedinc.com> writes: 
> Chris Emerson wrote:
> > It's not specified directly, I think, but the called function doesn't
> > necessarily know how many parameters were passed in (eg printf).
> 
> I'm not familiar enough in C to remember how variable number of arguments
> are handled in the language, but wouldn't that need to be described somehow
> in the routine declaration?  If so, the comipler could use different passing
> conventions for routines that accept variable number of arguments.
> 
> Even if not, I can think of other means of supporting variable number of
> arguments than requiring caller cleaned stack.

The C implementations always use caller cleans stack convention. Better
compilers allow one to choose at compile time, per subroutine (C call 
convention or Pascal call convention). The variable arity function I gave as 
an example in another posting ( foo( int arg, ... ); <- the three dots are 
valid C syntax ) is the way it is implemented, e.g. there must be at least 
one named argument of known type, and the caller takes it from there. Usually
this argument is the argument count proper. The callee must know the type of
each argument (at runtime). Basically C is a simple stack based machine, it 
pushes arguments to a subroutine on the stack, then calls it.

function:

int foo( int bar, char *p ) {
  int b = 1;
  int x = 3,y; // useless variables

  ++p;

  return (x=b*3+2);
}

stack at function entry call time:

[(ptr_width)p] <- the next argument ...
[(int_width)bar] <- leftmost argument is ALWAYS the first one above the ret. a.
[return address] <- sp points past here

now the function saves sp and puts its local variables on the (same!) stack,
which will look like:

[p]
[bar]
[return addr]___________v function uses the stack below this line
[bx] <- subroutine saves bp, then does mov bp, sp
[b==1]
[x]
[y] <- sp points past here

;; subroutine code, x86ish conventions
foo:
  push bx ; save caller's bp
  mov bx, sp ; copy sp to access parameters on stack
  ; function arguments have positive offsets and local vars have negative ones
  movw ax,1 ; b local variable
  push ax 
  movw ax, 3 ; x local var
  push ax
  push ax ; y local var, uninitialized

;; ++p
  incw [bx-offset(p)]

;; inside compiled code for return(x=y=b*3+2)
;; this is totally unoptimized code
;; b
  push offset(b)
  call fetch ; stack arithmetic evaluator, fetch b, consume address
;; 3
  pushw 3 ; stack 3
;; *
  call mulw ; multiply top 2 stack elements, leave one result on stack
;; 2
  pushw 2 ; put 2 on stack
;; +
  call addw ; add top 2 elements, consume one, leave result on top

;; now the rhs part of the argument of return() is on the stack
;; x=...
  push offset(x) ; prepare to assign x
  call assign ; consume address at top of stack and copy next element to x=
;; y=...
  push offset(y) ; prepare to assign y
  call assign ; same as above, y=

;; now we are ready to return, put the value at the top of the stack
;; in a predetermined register and then restore the old sp and return

pop ax ; this is the return value
mov sp, bx ; point stack at (just below) saved bx
pop bx
ret ; with result in ax

note that there are ways to return data wider than the accumulator by leaving
it on the stack (overwriting the local variables just after the saved bp). this
is necessary on machines that have a narrow word size (e.g. pics and not only) 
that wish to implement wide pointers. Typically the widest return type equals 
the widest register width available to pass the data in, but the stack can be 
used to make it as wide as necessary, regardless of the register (d,q)word 
width.

You can read more about it here (among other places):

http://www.nasm.us/doc/nasmdoc9.html
http://www.codeproject.com/KB/cpp/calling_conventions_demystified.aspx

For compiler flags that switch the C/Pascal style cleanup see __cdecl and
__stdcall on Google. Borland has these (I assume M$ also has them). On *nix
foobaring the call convention will result in nonfunctional code, the usual
standard is the one established by Intel with their iBCS2 which specifies just
this (the function call interface). There are other specs for kernel calls 
however.

other:
http://www.linuxjournal.com/article/2809

Peter


-- 
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist