Re: Why is GForth-ITC fast?

According to Robert Spykerman  <robert.spykerman@[EMAIL PROTECTED]
>:
> I was wondering why linus was stuffing parameters in registers to make
> linux syscalls, instead of pu****ng to the stack. I must ask a linux
> kernel hacker.

The kernel and the application code (so-called "userland") do not run
with the same privilege levels (the kernel code is allowed to tinker
with the hardware, not the userland). A system call is a jump between
the two worlds, usually through a software interrupt or an equivalent
mechanism. That jump entails a "stack switch", which means that the
kernel code obtains its own stack (the stack pointer register value is
saved, and the value for the kernel recovered during the switch; the
reverse operation occurs when the system call returns). To access
the userland stack, the kernel must first recover the userland stack
pointer.

Besides, the userland is not trusted by the kernel. The stack pointer
could be bogus, or point to a part of the memory which the kernel can
physically access (with its "kernel rights") but the userland cannot.
Before accessing the user stack, the kernel would have to check whether
that memory area is safe, which is doable (and actually done for system
calls such as read() or write() which exchange data chunks with the
userland) but somewhat complex and expensive. Besides, the kernel really
needs a safe stack of its own (the userland stack could be concurrently
modified from another thread, hence the kernel cannot safely store its
own data in it).

Hence it is safer and simpler to exchange data through registers when
possible. As an added bonus, this means that the userland code needs not
maintain a C-like stack, if it runs code written in a language which
does not have that concept, or would like to reuse the stack pointer
register for other usages (except for signals, but there is the
sigaltstack() system call for that).


	--Thomas ****in