|Compiling an ellipsis gcome@NOSPMcyberus.ca (Guillaume Comeau) (1999-11-21)|
|Re: Compiling an ellipsis firstname.lastname@example.org (Alan Donovan) (1999-11-23)|
|Re: Compiling an ellipsis email@example.com (Zalman Stern) (1999-11-23)|
|Re: Compiling an ellipsis firstname.lastname@example.org (James Jones) (1999-11-23)|
|From:||Zalman Stern <email@example.com>|
|Date:||23 Nov 1999 00:40:49 -0500|
Guillaume Comeau <firstname.lastname@example.org> wrote:
: Hence the question: are parameters in ellipsis forcefully on the
: operand stack, or can they be in internal registers as space allows?
: (in which I have some assembly work to do for each processor port).
Usually, the calling convention reserves space in the stack frame for
the parameters that are passed in registers. (Imprecisely, as many
bytes as the registers take up and contiguous with the paramters after
those passed in registers.) The compiler arranges that the first thing
a varags function does is to store all of the registers used for
parameter passing into the reserved slots in the stack frame. (I've
heard this called "homing" the parameters.") Then the variable
argument accessor routines can be implemented using macros that do
casts and pointer manipulation since all the arguments are now in a
contiguous block. (Except for padding of course, but most calling
conventions require that the padding can be deduced from only the size
of a type.)
The above ends up placing some requirements on the calling convention.
Mainly that all properties of the calling convention have to depend on
the size of items, not their precise type. Though games get played
even there to support floating-point argument passing in
registers. Ultimately, the compiler could take a different approach
for caling varargs and non-varags routines if there are prototypes in
scope. Most don't because lots of legacy code would break.
Return to the
Search the comp.compilers archives again.