Why/when are traps used rather than explicit system calls? Is it just historical coevolution? Or is the idea that the user mode program doesn’t need to know that it’s unprivileged? Or is it just repurposing the error handler path to perform privileged operations?
Most processors support both "interrupts" (an external peripheral is banging on the CPU's interrupt pins... but also invocable from software; software interrupts; SWIs; INT instruction on x86) and "exceptions" (e.g. divide by zero, bus error, illegal instruction). Depending on the processor, accessing the "privileged" mode can be done either by software interrupts, exceptions, or both. An operating system should pick one and stick with it.
Other uses for interrupt/exception/trap vectors include hardware breakpoints: don't try and single-step the CPU, overwrite the code with an illegal instruction and control will flow to the illegal instruction handler where you can see all the registers then execute the real instruction that was meant to be there and return to where you left off. Some CPUs have a formal "BKPT" type instruction for that.
One other use on the 68000 is that any unrecognised instruction that started $Fxxx triggered the F-line handler; all the floating point instructions were in the form $Fxxx, so if you didn't have an FPU, you could put a software emulator for the FPU instructions in the F-line handler and software wouldn't know the difference. Traps/exceptions don't have to be a jump from unprivileged to privileged, they can just be utilitarian.
At the time of DOS, x86 didn't have multiple privileges. The system call instruction was typically INT, the software interrupt instruction.
Later on the 386 Intel added virtual 8086 mode which trapped to the kernel privileged instruction exception also for certain instructions that had to be virtualized, among them INT.
Depends on the processor architecture and its nomenclature.
Traps typically also result from exceptional conditions (like divide by zero or page fault).
An architecture may or may not provide non-trap paths for less-privileged code to invoke more-privileged subsystems (call gates, "syscall" instructions, etc.).
Traps typically need some way to preserve all userspace-accessible registers (otherwise resuming from a page fault is .. hard). Dedicated syscall instructions may only need to restore a subset of registers.
In some implementations, processors may discover that an instruction must trap after it starts irreversibly changing architecturally-visibile state; in cases like that, the processor needs to leave enough breadcrumbs for the OS to allow either a clean unwind or a resumption of the interrupted instruction. My understanding is that the original 68000 somewhat famously got this wrong.
I don't know OG x86 (cuz, ewww) but on 68k this was generally the way. On my Atari ST a syscall was performed by filling your registers and stack as expected, then executing one of the TRAP opcodes and that would get the CPU To save PC etc & jump to the handler but in supervisor mode, where your syscall could then read state perform accordingly, and then return back to you.
I think x86_64 has just formalized this into a specific SYSCALL instruction?
ARM variants call it SVC (supervisor call).
Same difference.
Some older operating systems just implemented their syscalls as ordinary subroutine jumps, though, and everything ran in supervisor etc. I believe AmigaOS was like this, you just went through a jump table. Which, I think, shaves some cycles but also means compromises in terms of building for memory protection, etc.
if you know a particular process or system callmakes errors,then you run code that checks for that error,or exception,or preempively hooks a problematic system call,to redirect to "your"code that handles the state of exception,and returns.
Similar but traps are triggered automatically on attempts to execute a protected instruction.
https://www.geeksforgeeks.org/operating-systems/traps-and-sy...
Why/when are traps used rather than explicit system calls? Is it just historical coevolution? Or is the idea that the user mode program doesn’t need to know that it’s unprivileged? Or is it just repurposing the error handler path to perform privileged operations?
As others have said, a trap is one way to implement system calls. It's literally the TRAP mnemonic on a 68000.
https://www.nxp.com/docs/en/reference-manual/M68000PRM.pdf see page 292, also see page 629 for the table of "exception vectors" (addresses for code to handle each specific trap/exception/interrupt)
Most processors support both "interrupts" (an external peripheral is banging on the CPU's interrupt pins... but also invocable from software; software interrupts; SWIs; INT instruction on x86) and "exceptions" (e.g. divide by zero, bus error, illegal instruction). Depending on the processor, accessing the "privileged" mode can be done either by software interrupts, exceptions, or both. An operating system should pick one and stick with it.
Other uses for interrupt/exception/trap vectors include hardware breakpoints: don't try and single-step the CPU, overwrite the code with an illegal instruction and control will flow to the illegal instruction handler where you can see all the registers then execute the real instruction that was meant to be there and return to where you left off. Some CPUs have a formal "BKPT" type instruction for that.
One other use on the 68000 is that any unrecognised instruction that started $Fxxx triggered the F-line handler; all the floating point instructions were in the form $Fxxx, so if you didn't have an FPU, you could put a software emulator for the FPU instructions in the F-line handler and software wouldn't know the difference. Traps/exceptions don't have to be a jump from unprivileged to privileged, they can just be utilitarian.
1 reply →
At the time of DOS, x86 didn't have multiple privileges. The system call instruction was typically INT, the software interrupt instruction.
Later on the 386 Intel added virtual 8086 mode which trapped to the kernel privileged instruction exception also for certain instructions that had to be virtualized, among them INT.
6 replies →
Depends on the processor architecture and its nomenclature.
Traps typically also result from exceptional conditions (like divide by zero or page fault).
An architecture may or may not provide non-trap paths for less-privileged code to invoke more-privileged subsystems (call gates, "syscall" instructions, etc.).
Traps typically need some way to preserve all userspace-accessible registers (otherwise resuming from a page fault is .. hard). Dedicated syscall instructions may only need to restore a subset of registers.
In some implementations, processors may discover that an instruction must trap after it starts irreversibly changing architecturally-visibile state; in cases like that, the processor needs to leave enough breadcrumbs for the OS to allow either a clean unwind or a resumption of the interrupted instruction. My understanding is that the original 68000 somewhat famously got this wrong.
Traps were/are the mechanism for doing syscalls.
I don't know OG x86 (cuz, ewww) but on 68k this was generally the way. On my Atari ST a syscall was performed by filling your registers and stack as expected, then executing one of the TRAP opcodes and that would get the CPU To save PC etc & jump to the handler but in supervisor mode, where your syscall could then read state perform accordingly, and then return back to you.
I think x86_64 has just formalized this into a specific SYSCALL instruction?
ARM variants call it SVC (supervisor call).
Same difference.
Some older operating systems just implemented their syscalls as ordinary subroutine jumps, though, and everything ran in supervisor etc. I believe AmigaOS was like this, you just went through a jump table. Which, I think, shaves some cycles but also means compromises in terms of building for memory protection, etc.
if you know a particular process or system callmakes errors,then you run code that checks for that error,or exception,or preempively hooks a problematic system call,to redirect to "your"code that handles the state of exception,and returns.
https://en.wikipedia.org/wiki/Interrupt#Terminology
Before SYSCALL there was INT
I remember SVC. and also things like BR14 and IEFBR14
It's a trap
Need to pee? Take the a-trap to Shell.
[dead]