Syscall/Sysret state on i386 arch

From: alexander (arundel_at_h3c.de)
Date: 08/28/05

  • Next message: Doug Barton: "Re: [PATCH] caching daemon release and nsswitch patches" 
    Date: Sun, 28 Aug 2005 16:32:39 +0200
To: freebsd-hackers@freebsd.org

    The AMD64 arch is using the syscall/sysret opcodes instead of int80h to perform
    a syscall (/usr/src/lib/libc/amd64/SYS.h). I just checked the output my of
    dmesg and it says:

    CPU: AMD Duron(tm) Processor (1311.69-MHz 686-class CPU)
      Origin = "AuthenticAMD" Id = 0x671 Stepping = 1
      Features=0x383f9ff<FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,SEP,MTRR,PGE,MCA,CMOV,\
      PAT,PSE36,MMX,FXSR,SSE>
      AMD Features=0xc0400800<SYSCALL,MMX+,3DNow+,3DNow>

    I got a hold of the AMD document number 21086.pdf. It describes both opcodes
    pretty well, but doesn't tell which CPUs support the new opcodes. But since the
    first revision of that document is dated Sept 1997 quite a lot of i386 CPU's
    should support the opcodes. The NASM manual only states [P6,AMD] as the
    required CPU to perform those opcodes.

    I found some patches for Linux that replace the int80h syscall calling
    convention with syscall/sysret on i386 and the results look pretty convincing:

    > (INT $0x80 based getpid(), got pid 497) latency:282 cycles
    > (SYSENTER based getpid(), got pid 497) latency:138 cycles
    >
    > on a 266 MHz PII this is 0.51 usecs for a getpid(). (was 1.06 usecs)

    Quoted from: http://www.ussg.iu.edu/hypermail/linux/kernel/9806.1/0878.html

    Does anybody know more about this? Is it even possible to replace the current
    syscall implementation that easily or would that require elaborate changes to all the
    syscalls (libc), etc. And which CPU's support these new opcodes? Doesn anybody know if
    the Linux patches actually got comitted to the official kernel?

    Cheers.
    _______________________________________________
    freebsd-hackers@freebsd.org mailing list
    http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
    To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org"

  • Next message: Doug Barton: "Re: [PATCH] caching daemon release and nsswitch patches"

    Relevant Pages

    • Re: <ctype.h> toLower()
      ... A compiler is designed to create opcodes for a specific CPU. ... > You seem to be confusing object files with an Executable Image. ...
      (alt.comp.lang.learn.c-cpp)
    • Re: <ctype.h> toLower()
      ... CPU, opcodes, operating system ... You can specify the target platform and the object file works on whatever ... Microsoft Windows NTŪ operating system. ...
      (alt.comp.lang.learn.c-cpp)
    • Re: CPU design
      ... >> Why not use PicoBlaze, ... > I think I can synthesize my CPU with less gates. ... That probably means 16 bit opcodes (down from the 18 allowed by Block Ram), and 32 bit registers, with plenty of size-extended opcodes, and skip opcodes. ...
      (comp.arch.fpga)
    • Re: Syscall/Sysret state on i386 arch
      ... > I got a hold of the AMD document number 21086.pdf. ... > opcodes pretty well, but doesn't tell which CPUs support the new opcodes. ... Support for syscall/sysret is determined by a cpuid flag. ...
      (freebsd-hackers)
    • Re: CPU design
      ... PicoBlaze looks a bit like my idea: ... I think I can synthesize my CPU with less gates. ... That probably means 16 bit opcodes (down from the 18 allowed by Block Ram), and 32 bit registers, with plenty of size-extended opcodes, and skip opcodes. ...
      (comp.arch.fpga)