Subject: Re: Lmbench results for Linux/MIPS 2.1.90

From: [email-masked]
Date: Sun, 5 Apr 1998 14:42:33 +0200

On Sun, Apr 05, 1998 at 12:15:22PM +0100, Dominic Sweetman wrote:

> [email-masked] ([email-masked]) writes:
> 
> > I'm thinking about changing the calling sequence of syscalls as well.
> > When we get more than four arguments passed, we have to dig them out of
> > the userstack.
> 
> Someone else mentioned n32/64; these new SGI standards pass up to 8
> arguments in registers.
> 
> Making syscalls different from all other function calls would be kind
> of a kludge.

Syscalls already are different from other calls.  Linux handles them exactly
the same as RISC/os or IRIX.  Four arguments passed in a0 - a3, the syscall
number in v0 and the result is being returned in v0 and an error flag in a3.
Some syscalls even cannot be reasonably be called from a user context, for
example clone(2), ptrace(2), sigreturn(2); they do require special wrappers
due to the nature of what they're doing.

The problem with the argument passing convention is the case when we have
more than 4 arguments.  In that special case we need to get the additional
arguments from the userstack.  Which again - especially for Linux 2.0 was
_very_ expensive because the user stackpointer had to be verified - user might
try to fool the kernel like ``li sp, -1, syscall''.  Still the special
handling for stackargs produces a certain overhead and passing all arguments
in registers would solve that.  The newer calling conventions are essentially
nothing else than I was suggesting above; they are using temporary registers
$t4 - $t7 as the additional argument registers $ta0 - $ta3.

I don't consider the fact that this would introduce another calling
convention for syscall arguments to be very relevant, let alone kludgy.  In
fact things would look nicer that way, no more stack arguments (no syscall has
more than 6 args) and the argument passing convention would allow for the
same syscall handler to be user for all user programs - no matter wether
they are 32 bit or future n32 and 64 bit code.  Only the binary compatibility
for IRIX would need some special treatment.  Even better, the whole matter can
be dealt with in a matter that is invisible to users - as long as no static
linked code is involved.  And it can be done slowly such that nothing of
importance breaks.

  Ralf