Editing System call (section)

== Typical implementations ==
Implementing system calls requires a transfer of control from user space to kernel space, which involves some sort of architecture-specific feature. A typical way to implement this is to use a [[software interrupt]] or [[Trap (computing)|trap]]. Interrupts transfer control to the operating system [[Kernel (operating system)|kernel]], so software simply needs to set up some register with the system call number needed, and execute the software interrupt.

This is the only technique provided for many [[RISC]] processors, but [[Complex instruction set computer|CISC]] architectures such as [[x86]] support additional techniques. For example, the x86 [[instruction set]] contains the instructions <code>SYSCALL</code>/<code>SYSRET</code> and <code>SYSENTER</code>/<code>SYSEXIT</code> (these two mechanisms were independently created by [[AMD]] and [[Intel]], respectively, but in essence they do the same thing). These are "fast" control transfer instructions that are designed to quickly transfer control to the kernel for a system call without the overhead of an interrupt.<ref>{{cite web|url=http://wiki.osdev.org/SYSENTER|title=SYSENTER |website=OSDev wiki |url-status=live |archive-url=https://web.archive.org/web/20231108202438/https://wiki.osdev.org/Sysenter |archive-date= Nov 8, 2023 }}</ref> [[Linux]] 2.5 began using this on the [[x86]], where available; formerly it used the <code>[[INT (x86 instruction)|INT]]</code> instruction, where the system call number was placed in the <code>EAX</code> [[processor register|register]] before [[INT (x86 instruction)|interrupt]] 0x80 was executed.<ref>{{cite web |url=http://kerneltrap.org/node/531 |title=Linux 2.5 gets vsyscalls, sysenter support |access-date=2008-01-01 |author=Anonymous |date=2002-12-19 |work=[[KernelTrap]]}}</ref><ref>{{cite web|url=http://articles.manugarg.com/systemcallinlinux2_6.html|title=Sysenter Based System Call Mechanism in Linux 2.6|date=2006|author=Manu Garg}}</ref>

An older mechanism is the [[call gate]]; originally used in [[Multics]] and later, for example, see [[call gate (Intel)|call gate]] on the Intel [[x86]]. It allows a program to call a kernel function directly using a safe control transfer mechanism, which the operating system sets up in advance. This approach has been unpopular on x86, presumably due to the requirement of a far call (a call to a procedure located in a different segment than the current code segment<ref>{{cite web|url=http://x86.renejeschke.de/html/file_module_x86_id_26.html|title=Liberation: x86 Instruction Set Reference|work=renejeschke.de|access-date=4 July 2015}}</ref>) which uses [[x86 memory segmentation]] and the resulting lack of [[portability (software)|portability]] it causes, and the existence of the faster instructions mentioned above.

For [[IA-64]] architecture, <code>EPC</code> (Enter Privileged Code) instruction is used. The first eight system call arguments are passed in registers, and the rest are passed on the stack.

In the [[IBM System/360]] mainframe family, and its successors, a [[Supervisor Call instruction]] ({{mono|SVC}}), with the number in the instruction rather than in a register, implements a system call for legacy facilities in most of{{efn|The CP components of [[CP-67]] and [[VM (operating system)|VM]] use the Diagnose (DIAG) instruction as a Hypervisor CALL (HVC) from a virtual machine to CP.}} IBM's own operating systems, and for all system calls in Linux.  In later versions of MVS, IBM uses the Program Call (PC) instruction for many newer facilities. In particular, PC is used when the caller might be in [[Service Request Block]] (SRB) mode.
<!-- Does z/VSE use PC? -->

The [[PDP-11]] [[minicomputer]] used the {{mono|EMT}}, {{mono|TRAP}} and {{mono|IOT}} instructions, which, similar to the IBM System/360 {{mono|SVC}} and x86 {{mono|INT}}, put the code in the instruction; they generate interrupts to specific addresses, transferring control to the operating system.  The [[VAX]] 32-bit successor to the PDP-11 series used the {{mono|CHMK}}, {{mono|CHME}}, and {{mono|CHMS}} instructions to make system calls to privileged code at various levels; the code is an argument to the instruction.