DragonflyBSD fast syscall support and x86 improvements

Attilio Rao attilio at freebsd.org
Mon Jun 26 08:43:20 PDT 2006

2006/6/26, Thomas E. Spanjaard <tgen at xxxxxxxxxxxxx>:
Matthew Dillon wrote:
>     For better or for worse, the IA32 ABI is stack-based.  Believe me,
>     being an old Amiga guy I would *LOVE* to see the registerized call
>     standard be the default rather then a special GCC '__blah' qualifier.
Well, the ISA is, but the underlying micro architecture isn't. The ISA
doesn't expose the problems with memory access in stack-based languages,
but the CPUs do experience those. With a Hobbit or ARM with Java
extensions you would have less of an issue with this. So I think you can
get real performance advantages when optimizing for the actual RISC
register-based core behind the IA32 ISA. How is a bit of a problem,
since you can't use the whole lot of registers actually available due to
register renaming, but I think x86-64 in 64b long mode has more GP
registers available, no? An optimization for AMD64 (together with a port
of DragonFlyBSD to it ;)) would be very, very neat :).
Matthew is right when he says that doing something as Linux does about
syscalls (using GP registers for parameters gathering) is painful and
useless since, in the middle of your code, you need to reuse them in
the exception handler 80h or in the sysenter kernelspace entry point.
In the case of sysenter, this is stressed as long as possible beacause
you need to pass eip/esp of level 3 through GP registers, possibly.
For this reasons, a good point would be using a different set of
registers for this and not accessing directly to both stacks
(uspace/kspace) would give a nice speedup (even if it's in L1, would
be nicely evaluable for a big number of syscalls, ~1000+).
The main problems of this are linked to context stealing for used
registers (possibly we could feed gcc about it), evaluating the
possible better split in chunks of 32 bits for registers etc etc. It
will give an overhead that could vanify all our improvements.

Peace can only be achieved by understanding - A. Einstein

More information about the Kernel mailing list