DragonFly BSD
DragonFly kernel List (threaded) for 2006-06
[Date Prev][Date Next]  [Thread Prev][Thread Next]  [Date Index][Thread Index]

Re: DragonflyBSD fast syscall support and x86 improvements


From: "Attilio Rao" <attilio@xxxxxxxxxxx>
Date: Mon, 26 Jun 2006 15:42:29 +0200

2006/6/26, Thomas E. Spanjaard <tgen@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.

Attilio


-- Peace can only be achieved by understanding - A. Einstein



[Date Prev][Date Next]  [Thread Prev][Thread Next]  [Date Index][Thread Index]