Software Engineering Stack Exchange is a question and answer site for professionals, academics, and students working within the systems development life cycle. It only takes a minute to sign up.
Sign up to join this community
To execute a system call, a program must execute a special trap instruction.
Why is it called a "trap" instruction? What is the etymology of this usage of the word "trap"?
Is it related to the usual English word trap? Is something is getting "trapped" as in "unable to escape"?
It's what we call kernel or system "trap", which triggers a kernel mode switch to execute the system call.
As to why that word was used, I haven't found definitive proof yet, so my current assumption is that it comes from either or both of these 2 options:
We used to say sometimes that the code "fell" into a different mode instead of "switching", which resembles the mental image of "falling into a trap".
A "trap" is meant to capture something, here a reaction to an interrupt, which can happen in case of a failure (which can have several levels of severity, including being "fatal").
Furthermore, and along the same lines of thinking, we usually think of a program's control flow as having a "normal" flow and having an "error" or "exceptional" flow for things that should not (or rarely) happen. And the point of the "trap" is to capture such events.
But I think the sentence you quote is strangely worded.
While we can all say that the concept of "trap on overflow", or "trap on divide by zero" makes intuitive sense – stop the program from proceeding — what I would do is look to the various traditional vendors since terminology from days of yore was not standardized (and perhaps still isn't).
The terms 'exception', 'software interrupt', 'interrupt', 'trap', 'fault' all have very similar meanings in certain environments.
While I don't know who really started it, the term trap is heavily used by Motorola, what with the 6800 (development started 1971, released 1974) and later 68000 processors.
The Intel docs of today use the term but I don't see it in docs for older Intel processors, e.g. 8080. With the Intel 8086 (1976) I see the term trap being used to mean single stepping the processor, which I don't see for the older 8088.
For me the term "trap" always invoked the notion of suddenly seizing control of something unexpectedly and against its will.
If you think of the "something" as "normal program flow", then that's a pretty good description of what a software trap does.
According to Wikipedia, first: the nomenclature of "trap" varies pretty wildly between systems:
There is a wide variation in the nomenclature. On some computers the term trap refers to any interrupt, on some machines to any synchronous interrupt, on some machines to any interrupt not associated with input/output, on some machines only to interrupts caused by instructions with trap in their names, etc.
According to a 1996 article by Randall Hyde cited,
The concept of an interrupt is something that has expanded in scope over the years. The 80x86 family has only added to the confusion surrounding interrupts by introducing the int (software interrupt) instruction. Indeed different manufacturers have used terms like exceptions faults aborts traps and interrupts to describe the phenomena this chapter discusses. Unfortunately there is no clear consensus as to the exact meaning of these terms. Different authors adopt different terms to their own use. While it is tempting to avoid the use of such misused terms altogether for the purpose of discussion it would be nice to have a set of well defined terms we can use in this chapter. Therefore we will pick three of the terms above interrupts traps and exceptions and define them. This chapter attempts to use the most common meanings for these terms but don't be surprised to find other texts using them in different contexts.
A 'trap' is whatever the system in question defines it to be ... but it's generically something akin to an error condition, special system interrupt, or other "unusual" condition.
'Trap' because it intercepts an exception. When the CPU issues an "undefined operation" exception, it switches into supervisor mode and checks the low-order part of the instruction for an index into a jump table of routines which implement the desired behavior, for example, software floating point routines. If no such entry point exists, you get the expected kaboom!
The evolution and absorption of hardware terminology into modern systems and software usage is an interesting one. For many, the true etymology was lost before many of us were even born. In most cases, the original meanings of words have been adopted to have similar technical meaning. For instance, we don't give "memory" a second thought, despite the fact the mechanisms for achieving data storage and retrieval in hardware varies significantly, and all are substantively different than that of human memory.
In the absence of historical evidence to the contrary, we should look at the English definition of the word trap (emphasis is mine):
1 a contrivance used for catching game or other animals, as a mechanical device that springs shut suddenly.
Consider the electrical engineer (EE) who designed the first trap circuit. What was the design goal and how did they achieve it? I believe it was either the HALT or TRAP instruction, or the effect of the first fault detector; which originally was designed to halt execution of electromechanical computing or control devices when software or hardware detection of any state which could result in damaged hardware or loss of resources, that was the progenitor of these terms into the systems software lexicon.
The first programs ever written, were punched into leather belts that controlled steam driven looms. The primary drive wheel to which the steam piston or cylinder was attached, were often made of Iron or wood and > 8' in diameter (I worked on a mill once, with a 16' cast iron drive wheel) and could not be stopped quickly, due to inertia. If there was a failure (fault) of the leather control belt (the program), a mechanical device would "immediately" disengage the drive belt from the machine to which it was attached, and in some cases, a break would be applied at that machine. In that era, the lexicon was driven by mechanical engineers (ME's) and millwrights, not unfamiliar with the use of mechanical traps for catching game or vermin.
Fast forward about 75 years to that EE designing the first fault detection and trapping circuits back in the late 1930's or early 1940's. I believe a search of the earliest computing hardware patents would probably turn up some of the earliest mentions of faults and traps in relation to computing devices. Most of the earliest systems software lexicon was adopted from that first generation of EE's and their proteges.
I can suggest my own speculation on it. The oldest mention of "trap" in computer engineering that I have found is from 1955 and the IBM 704 manual. This blog post by a Norman Hardy also mentions the IBM 704 being his first experience with "traps, and this page from Mark Smotherman also lists the IBM 704 as one of the first uses of "traps" (he uses the word "trap" for UNIVAC I from 1951 and IBM 650 from 1954 but I've been unable to verify that the term was used by those systems back in 1951 and 1954. ) It may be interesting etymologically that "traps" in IBM 704 was actually a "trapping mode", a debug mode that transferred control to the debugger on every subroutine call (every branch operation, both conditional and unconditional). That the "trapping mode" was for debugging, is mentioned in the 1955 manual: "the major use of the trapping mode is in program testing, where it permits observation of the flow of control" (the 1955 manual, page 11). While the person doing the debugging still manually had to add "enter trapping mode" (ETM) instructions to the program, there is still a symbolic and metaphorical difference to a program making a system call as part of it's normal mode of operation. The IBM 704 use of the term "trap" is closer to the English word trap, that something is getting "trapped" as in "unable to escape", compared to a program making a kernel request to draw a square on the display or something like that. In the latter case, the program is expecting to resume operation when the kernel has fetched the resource, and it is not "trapped" (unless something happens to go wrong and control is never returned, but that is then caused by something other than the "software trap").
This speculation is easily falsified by showing the word "trap" in historical documentation prior to the IBM 704 and that it was not used as "trapping mode". Another answer for example suggested the term may have been used in 1930s and 1940s but I have not seen any documentation that shows that, nor have I found any for UNIVAC I or IBM 650. The answer is my own personal speculation, and I share it to the extent that there is room for some speculation in answers to the question.
