4 ms·

if I implemented a couple of traps What does this mean? System calls?

by CyberDildonics 5mo ago

jjk7 5mo ago
Before SYSCALL there was INT
- m463 5mo ago
  I remember SVC. and also things like BR14 and IEFBR14
hack1312 5mo ago
[dead]
rtkwe 5mo ago
Similar but traps are triggered automatically on attempts to execute a protected instruction. https://www.geeksforgeeks.org/operating-systems/traps-and-system-calls-in-operating-system-os/ https://www.geeksforgeeks.org/operating-systems/traps-and-sy...
- dullcrisp 5mo ago
  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?
  - Polizeiposaune 5mo ago
    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.
  - bonzini 5mo ago
    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.
    - JoeAltmaier 5mo ago
      Yes, exactly. We used a set of INT instructions in well-known low memory addresses that all jumped to the same place. We had an ASM file that you linked with, that had sixteen different address combinations for each. The common entry point would look back on the stack and calculate from the return address which entry point had been called, and run the appropriate kernel call. We called it the CS:IP hack. In the context of this post, the DOS INT10 and INTx(I forget) required the caller to load registers with the desired system call number, then perform the trap instruction in their code. Fortunately CTOS didn't need those particular software interrupts, so I could implement them for my purposes.
      - globalnode 5mo ago
        int 21h !
        somenameforme 5mo ago
        Need some params! mov ah, 2 mov dl,7 Ahhh.. probably my first program. Don't forget the int 20 at the end! It was beeping great. Still never unlocked the mysteries of those TSR programs though.
        thequux 5mo ago
        It's been a long time since I've touched any of this, so the details have slipped my mind. However, the general idea was that there were two different exit calls in DOS: terminate and terminate and stay resident. The difference between the two is that the stay resident option wouldn't release the memory used by your application. Further, the interrupt table, which told the processor how to handle each interrupt, was in RAM and therefore writable. So, what TSRs would do is overwrite one or more interrupts to point to a routine that would check if the system call in question was one it wanted to handle (eg, to add a hotkey it would grab the keyboard handler and check for a special set of keys before passing control back to the normal handler). Once that was fine, it would call the TSR system call and control would be passed back to the OS with the hook still in place
  - deleted 5mo ago
    [deleted]
  - cmrdporcupine 5mo ago
    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.
  - amiga386 5mo ago
    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 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.
    - achierius 5mo ago
      > 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. Practically most will support access via both, but for different reasons. For example, page faults (which the software cannot possibly predict) are going to be exception-mediated, but syscalls (which the software asks for) are triggered via an interrupt.
rolph 5mo ago
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 https://en.wikipedia.org/wiki/Interrupt#Terminology
fintler 5mo ago
Need to pee? Take the a-trap to Shell.
therealfigtree 5mo ago
It's a trap
- __patchbit__ 5mo ago
  The F-14 Tomcat had an early period microprocessor and landing on an aircraft carrier would have the tailhook snag arresting wires in a trap. But the trap idea precedes the Tomcat by a decade in computing according to the AI.

if I implemented a couple of traps What does this mean? System calls?

jjk7 5mo ago

Before SYSCALL there was INT

m463 5mo ago
I remember SVC. and also things like BR14 and IEFBR14

hack1312 5mo ago

[dead]

rtkwe 5mo ago

Similar but traps are triggered automatically on attempts to execute a protected instruction. https://www.geeksforgeeks.org/operating-systems/traps-and-system-calls-in-operating-system-os/ https://www.geeksforgeeks.org/operating-systems/traps-and-sy...

dullcrisp 5mo ago
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?
- Polizeiposaune 5mo ago
  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.
- bonzini 5mo ago
  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.
  - JoeAltmaier 5mo ago
    Yes, exactly. We used a set of INT instructions in well-known low memory addresses that all jumped to the same place. We had an ASM file that you linked with, that had sixteen different address combinations for each. The common entry point would look back on the stack and calculate from the return address which entry point had been called, and run the appropriate kernel call. We called it the CS:IP hack. In the context of this post, the DOS INT10 and INTx(I forget) required the caller to load registers with the desired system call number, then perform the trap instruction in their code. Fortunately CTOS didn't need those particular software interrupts, so I could implement them for my purposes.
    - globalnode 5mo ago
      int 21h !
      - somenameforme 5mo ago
        Need some params! mov ah, 2 mov dl,7 Ahhh.. probably my first program. Don't forget the int 20 at the end! It was beeping great. Still never unlocked the mysteries of those TSR programs though.
        thequux 5mo ago
        It's been a long time since I've touched any of this, so the details have slipped my mind. However, the general idea was that there were two different exit calls in DOS: terminate and terminate and stay resident. The difference between the two is that the stay resident option wouldn't release the memory used by your application. Further, the interrupt table, which told the processor how to handle each interrupt, was in RAM and therefore writable. So, what TSRs would do is overwrite one or more interrupts to point to a routine that would check if the system call in question was one it wanted to handle (eg, to add a hotkey it would grab the keyboard handler and check for a special set of keys before passing control back to the normal handler). Once that was fine, it would call the TSR system call and control would be passed back to the OS with the hook still in place
- deleted 5mo ago
  [deleted]
- cmrdporcupine 5mo ago
  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.
- amiga386 5mo ago
  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 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.
  - achierius 5mo ago
    > 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. Practically most will support access via both, but for different reasons. For example, page faults (which the software cannot possibly predict) are going to be exception-mediated, but syscalls (which the software asks for) are triggered via an interrupt.

rolph 5mo ago

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 https://en.wikipedia.org/wiki/Interrupt#Terminology

fintler 5mo ago

Need to pee? Take the a-trap to Shell.

therealfigtree 5mo ago

It's a trap

__patchbit__ 5mo ago
The F-14 Tomcat had an early period microprocessor and landing on an aircraft carrier would have the tailhook snag arresting wires in a trap. But the trap idea precedes the Tomcat by a decade in computing according to the AI.