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