why only 6 params passed in registers?
david...@my-deja.com
further arguments are passed on the stack. There are a total of 18
registers that are not saved across calls, why not allow them all to
contain parameters? Functions that acutally used > 18 parameters +
scratch registers would still have stack activity, but the others would
not.
Just wondering...
Sent via Deja.com http://www.deja.com/
Before you buy.
Alex Rhomberg
>
> On alpha unixen the first 6 parameters are passed in registers, and
> further arguments are passed on the stack. There are a total of 18
> registers that are not saved across calls, why not allow them all to
> contain parameters? Functions that acutally used > 18 parameters +
> scratch registers would still have stack activity, but the others would
> not.
Why bother? How many performance sensitive functions have more than 6
parameters?
- Alex
Martin Sinot
<david...@my-deja.com> wrote in message
news:85hhsi$lkj$1...@nnrp1.deja.com...
> On alpha unixen the first 6 parameters are passed in registers, and
> further arguments are passed on the stack. There are a total of 18
> registers that are not saved across calls, why not allow them all to
> contain parameters? Functions that acutally used > 18 parameters +
> scratch registers would still have stack activity, but the others would
> not.
>
Umm, how often do you have a function with 18 parameters? Or even six?
Remember that Alphas must have their data in registers to be able to
calculate with it. So a function requiring a large number of parameters
passed in registers probably would have to start with moving some of
these out of the way to be able to calculate. Then, it would be
difficult for such a function to call another function, as this would
destroy the parameter registers. Another need to save the parameter
registers, if you need them later on. Six registers can probably
fairly easy be copied to other registers, which are saved. In my
own programming practice, procedures taking six parameters are already
very rare, let alone functions requiring even more parameters.
So I think six registers to hold parameters is adequate. More is
not necessary and would cause inconvenience. And it's just not worth
the trouble.
--
Martin Sinot
Nijmegen, Netherlands
mar...@spase.nl
Serguei Patchkovskii
: Umm, how often do you have a function with 18 parameters? Or even six?
In numerical codes, it is not uncommon to have functions with half a
dozen parameters; I'd also seen function interfaces with more than
twenty parameters, with each one being there for a good reason. Of
course, such functions tend to perform a fair bit of processing of
their own - so that parameter passing style is not even a second-order
effect for them. The number of scratch registers, available for
intermediate results, is, on the other hand, very important for
such functions...
Cheers,
/Serge.P
--
home page: http://www.cobalt.chem.ucalgary.ca/ps/
Steven Hobbs
In article <85hhsi$lkj$1...@nnrp1.deja.com>, david...@my-deja.com writes:
>On alpha unixen the first 6 parameters are passed in registers, and
>further arguments are passed on the stack. There are a total of 18
>registers that are not saved across calls, why not allow them all to
>contain parameters? Functions that acutally used > 18 parameters +
>scratch registers would still have stack activity, but the others would
>not.
>
>Just wondering...
Consider the example of a varargs function, like printf in C. On
entry to printf, the routine does not know whether it has just 1
argument or 18 arguments or even more until it has decoded the format
string argument. It also does not not know whether the arguments are
in the floating registers or in the integer registers. With the
current calling standard printf needs to save 5 integer registers and
and 5 floating registers until it has decoded the format string. If
the calling standard passed 18 arguments in registers then printf
would need to save 17 integer registers and 17 floating registers.
This is a lot of overhead, given that most varargs routines (including
printf) rarely use these many arguments.
Chris
code to put all the args in a structure, then passing a pointer to it.
Voila, only a single register needed and you only have to add an element
to the structure, not change the function declaration, if you need to
add more args later.
I would never pass more than a couple of args to any function...
Rgrds, Chris
Martin Sinot
Steven Hobbs <ho...@steven.zko.dec.com> wrote in message
news:85lsaj$o6m$1...@mailint03.im.hou.compaq.com...
> Consider the example of a varargs function, like printf in C. On
> entry to printf, the routine does not know whether it has just 1
> argument or 18 arguments or even more until it has decoded the format
> string argument. It also does not not know whether the arguments are
> in the floating registers or in the integer registers. With the
> current calling standard printf needs to save 5 integer registers and
> and 5 floating registers until it has decoded the format string. If
> the calling standard passed 18 arguments in registers then printf
> would need to save 17 integer registers and 17 floating registers.
> This is a lot of overhead, given that most varargs routines (including
> printf) rarely use these many arguments.
If I remember correctly, only arguments which are actually
specified can be passed in registers. So in the printf case, there
is only one parameter passed in a register, the format string.
The variable arguments are always passed on the stack. Otherwise
you would need to keep track inside such a function where the
variable parameters actually are. That requires a lot of bookkeeping
and introduces a huge architecture dependency. As it is, printf
only needs to save the nonvolatile registers it actually uses
(the six parameter registers, int or float, need not be saved,
unless somebody requires a pointer to one of these parameters).
Serguei Patchkovskii
: You would make the code much more efficient and faster by writing the
: code to put all the args in a structure, then passing a pointer to it.
: Voila, only a single register needed and you only have to add an element
: to the structure, not change the function declaration, if you need to
: add more args later.
You win nothing doing this. The situation typical in numerical codes
is that most of the quantities have no "natural" association - they
are needed in different combinations for different fucntion calls. So,
you'll either end up passing huge structures unnecesarily, or you'll
end up stuffing your parameters into Yet Another Meaningless Struct
all the time - take your pick.
The things are not helped by the fact that most numerical codes are
written in Fortran, with substantial parts coming from many years
back and requiring the Fortran-77 interface style. As you probably
know Fortran-77 does not even *have* structures as a part of the
language - so it is kinda hard to use them ;-p)
: I would never pass more than a couple of args to any function...
Well, welcome to the real world.
Chris
>
> Chris (quatt...@dtn.ntl.com) wrote:
> : You would make the code much more efficient and faster by writing the
> : code to put all the args in a structure, then passing a pointer to it.
> : Voila, only a single register needed and you only have to add an element
> : to the structure, not change the function declaration, if you need to
> : add more args later.
>
> You win nothing doing this.
Wrong. If you have loads of args, they all have to be saved in registers
or on the stack for every call. This takes time and wastes resources. If
you are writing recursive code it's even worse.
> you'll either end up passing huge structures unnecesarily,
I did say pass a _pointer_ to it. A single arg irrespective of the
number of underlying function call args.
> end up stuffing your parameters into Yet Another Meaningless Struct
> all the time - take your pick.
It's programming style. If you organise your data efficiently, you'll
find structures become the natural place to put it.
>
> Well, welcome to the real world.
>
For me it's a case of trying to develop good programming habits -
thinking about data organisation before bashing out the code ;-).
Just $0.02, YMMV...
Rgrds, Chris
Steven Hobbs
>If I remember correctly, only arguments which are actually
>specified can be passed in registers. So in the printf case, there
>is only one parameter passed in a register, the format string.
>The variable arguments are always passed on the stack.
You do not remember correctly. Compile the following program on an
Alpha (I used both Compaq C and gcc):
extern void foo(char s[])
{printf(s, 1, 2.0, 3, 4, 5);}
and you will find 1,3,4,5 in r17,r19,r20,r21 and 2.0 in f18.
Notice that this example did not include <stdio.h> so the call on
printf is a "legacy" call on an undeclared function without a
prototype. A "legacy" caller cannot tell whether the called routine
uses varargs so all calls (legacy without a prototype, prototype
without an ellipsis terminator, and prototype with an ellipsis
terminator) must use the same register argument conventions.
Greg Lindahl
> You would make the code much more efficient and faster by writing the
> code to put all the args in a structure, then passing a pointer to it.
> Voila, only a single register needed and you only have to add an element
> to the structure, not change the function declaration, if you need to
> add more args later.
Spoken like a person who doesn't write Fortran.
Hint: if that was more efficient, all compilers would use it as their
argument passing convention.
-- g
Chris
>
> Chris <quatt...@dtn.ntl.com> writes:
>
> > You would make the code much more efficient and faster by writing the
> > code to put all the args in a structure, then passing a pointer to it.
> > Voila, only a single register needed and you only have to add an element
> > to the structure, not change the function declaration, if you need to
> > add more args later.
>
> Spoken like a person who doesn't write Fortran.
>
Correct, thankfully.
>
> Hint: if that was more efficient, all compilers would use it as their
> argument passing convention.
>
I wouldn't thing so, it's too high level. For example, All the Dec
compilers on Vax in the old days used a common calling convention, with
the same register usage and stack frame layout. This meant that you
could do strange stuff like link object modules using several different
source languages (basic, assembler, fortran, C, whatever) and it would
all run. Obviously this couldn't work if the calling convention used
language specific stuff like structures in C.
Vax VMS provided three calling conventions, call by value, call by
reference and call by descriptor. The latter was well suited to variable
length argument lists (Fortran ?) since at call level, the arguement
list has one entry, a pointer to a descriptor which itself contains the
length and address of the data. In fact, just another level of
indirection. As an analogy, you could think of that descriptor as a
structure in C.
It's been years since I did any VMS programming and haven't done any
Alpha systems programming under VMS, but would suspect that the same
techniques are still used on the latest Decpaq compilers under Vax VMS
and Tru64 unix.
Chris
Serguei Patchkovskii
: I wouldn't thing so, it's too high level. For example, All the Dec
: compilers on Vax in the old days used a common calling convention, with
: the same register usage and stack frame layout. This meant that you
: could do strange stuff like link object modules using several different
: source languages (basic, assembler, fortran, C, whatever) and it would
: all run.
You have a rather funny definition of "strange". Being able to combine
sections written in different languages within the same program is one
of the essential attributes of a quality compiler suite. Unless all you
have to do is to write 200-liners - naturally, in impeccable style with
exclusively 2-parameter functions in it.
Chris
from Macro32 assembler, which you could do if you were perverse enough
;-).
Having a common object file format across languages and calling
conventions was quite a revelation to me at the time, as was the fact
that it was fully documeneted with examples. Coming from Apple II and PC
environments, where you were lucky if the compiler vendor even disclosed
the call convention at all, never mind documented it properly. We take
stuff like that for granted now.
Chris
Serguei Patchkovskii
: that it was fully documeneted with examples. Coming from Apple II and PC
: environments, where you were lucky if the compiler vendor even disclosed
: the call convention at all, never mind documented it properly. We take
: stuff like that for granted now.
Having common object file format and language-neutral calling conventions
has been taken for granted in early sixties; there is nothing particularly
new or revolutionary to it. Naturally, it did not really matter for the
industry which used to be driven by gifted colledge dropouts and sax
virtuosos - *theey* didn't know it, and had to invent it the hard way. ;-)
Cheers,