Re: Why is GForth-ITC fast?

On May 1, 10:45 pm, Thomas Pornin <por...@xxxxxxxxx> wrote:

According to Robert Spykerman <robert.spyker...@xxxxxxxxx>:

I was wondering why linus was stuffing parameters in registers to make
linux syscalls, instead of pushing 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 Pornin

Ok points taken, the only thing is I guess if you want to do syscalls
the linux way on an IA-32 you kind of are starved of registers and (I
guess depending on code) you may have to save them first, then load
up EAX et al with the function call parameters then syscall...

This contrasts with OSX / BSD where you push the syscall parameters to
the userland stack and the kernel picks them up. I have to admit,
this seems to me slightly more convenient way of doing it.

I don't really know how expensive PUSH immediates or PUSH addresses
actually are I admit, offhand but I expect given the convenience they
apparently offer, they must be expensive.

Whichever is actually more efficient I do not know... I suspect it
depends on coding style.

Do you have any opinion on this (I'm just bloody curious)?

As you probably realize Thomas, my interest in syscalls is all in the
setting of trying to port Albert's ciforth/lina.

By the way, I've been warned by at least one person in the know at
Apple not to use int 0x80 syscalls on OS X, which apparently have been
left in for 'legacy code'. Nevertheless I got some pointers to where
in the source to look.

Does this sort of taboo exist on other *nixes as well? (I ask because
I'm still very much a nix nub/scrub)

The apple guys have warned me, but some BSD guys apparently have no
qualms in direct syscalls...

http://www.int80h.org/bsdasm/

Anyway, if I am not making sense I need to go to bed to reboot and fix
the memory leak in my brain. Any ideas on how to keep my brain real
time and mission critical graciously accepted :P

Robert Spykerman
.

Relevant Pages

  • Re: Timers and timing, was: MySQL Performance 6.0rc1
    ... How would a userland ... > ELF symbol table in the kernel as well. ... syscalls, we don't really need any real ELF symbols or something like ... The main point of all this is not to solve existing ABI compatibility ...
    (freebsd-current)
  • Re: Why is GForth-ITC fast?
    ... The kernel and the application code (so-called "userland") do not run ... That jump entails a "stack switch", ... kernel code obtains its own stack (the stack pointer register value is ...
    (comp.lang.forth)
  • Re: FreeBSD vs. OSX
    ... > userland tools and won't crash the whole system if they fail. ... > available patches that help running the ip stack in userland, ... simpler bulk of data transport handled by netgraph, in kernel space. ... Running the entirety of the IP stack in userland is an interesting ...
    (comp.unix.bsd.freebsd.misc)
  • [Full-disclosure] PHRACK 64: ATTACKING THE CORE
    ... - The Slab Allocator ... - Slab overflow exploiting: ... - Forcing a kernel path to sleep ... - Stack Frame Flow Recovery ...
    (Full-Disclosure)
  • Re: [Bug #11342] Linux 2.6.27-rc3: kernel BUG at mm/vmalloc.c - bisected
    ... stack usages for you is that they contain a 'cpumask_t' on the stack. ... We can enable MAXSMP and raise the CPU limits some time in the future. ... not accept a specially built kernel, but only a kernel that has been ... know how extensively these distributions test and certify for many known ...
    (Linux-Kernel)