DragonflyBSD fast syscall support and x86 improvements
Matthew Dillon
dillon at apollo.backplane.com
Fri Jun 23 17:31:22 PDT 2006
:> I think some degree of registerization might be beneficial, but with
:> the provisio that all we are doing here is passing the system call
:> arguments themselves in registers, not attempting to reimplement
:> the libc functions as registerized calls.
:
:Why not? The point is to not touch the uspace stack here from the
:program side and to not touch the kspace stack to kernel side. Even if
:we reasonably can assume L1 stacks for successive hits...(so the
:improvement is not so important here...).
:
:Attilio
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.
We're stuck with it and I really do not want to go through the
months of pain that would be caused if we triedto change the default.
If I understand correctly, the IA64 standard is registerized by default
(but I could be wrong).
Also, as far as IA32 goes, the limited number of registers makes it
questionable whether trying to pass more then a few arguments actually
saves anything.
More concretely, GCC generally no longer uses pushl but instead uses
movl <qty>,offset(%esp), and generally tries to maintain some stack
reserve for storing call arguments. Such operations are far easier for
the cpu to pipeline then pushl. The pipeline will pick the data right
out of the write buffer much of the time. The only real performance
issue is with the cpu's write buffer itself (though in newer AMD
architectures where caches can master dirty data, even that becomes
a non-issue as well because the data winds up hardly ever being flushed
to dynamic ram).
-Matt
Matthew Dillon
<dillon at xxxxxxxxxxxxx>
More information about the Kernel
mailing list