1 Sep
2021
1 Sep
'21
7:23 p.m.
I hope that this does not start any kind of language flaming and that if
something starts the moderator will shut it down quickly.
Where did the name for abort(3) and SIGABRT come from? I believe it was
derived from the IBM term ABEND, but would like to know one way or the
other.
1 Sep
1 Sep
7:28 p.m.
On Wed, Sep 1, 2021 at 9:25 AM Richard Salz <rich.salz(a)gmail.com> wrote:
I hope that this does not start any kind of language
flaming and that if
something starts the moderator will shut it down quickly.
Where did the name for abort(3) and SIGABRT come from? I believe it was
derived from the IBM term ABEND, but would like to know one way or the
other.
Caveat that I don't know the answer to the question, but "abort" to cease
doing something is pretty common in a lot of contexts; I always assumed
this was picked up in the same way one would "abort the mission" or "abort
the test flight" or something of that nature.
As an aside, I'd always been under the impression that the "AB" in
"ABEND"
comes from, "abnormal"?
- Dan C.
7:44 p.m.
On Wed, Sep 1, 2021 at 9:29 AM Dan Cross <crossd(a)gmail.com> wrote:
As an aside, I'd always been under the impression
that the "AB" in "ABEND"
comes from, "abnormal"?
That was what taught when I was hacking on TSS/360 (before I even saw UNIX).
The term was used in the IBM batch system to say your job died or
stopped with an abnormal ending (*i.e.* The job returned exit(NONZEROVALUE) to
the OS in UNIX terms [or the OS killed it for some reason and forced it to
exit in that manner].
As for Richard's question about abort(), no idea. I had heard the term
used to kill off an errant process/job/task used in other systems before I
ever came to Unix. You'd probably need some like Doug M or Knuth that
goes back far enought to help you with history.
ᐧ
8:23 p.m.
On 9/1/21, Dan Cross <crossd(a)gmail.com> wrote:
As an aside, I'd always been under the impression that the "AB" in
"ABEND"
comes from, "abnormal"?
You are correct, Dan. ABEND comes from the IBM (specifically
OS/360/370) world and is short for "abnormal end". It means that
application program (called the "problem program" in IBM mainframe
jargon) has terminated abnormally for some reason and control has
returned to the operating system. An ABEND was typically followed by
a core dump to the printer. As the manual for beginning programmers
at Boston College said, "Despite what your German teacher might tell
you, there is no such thing as a guten ABEND."
-Paul W.
8:29 p.m.
We know that SIGABRT was once SIGIOT, which was what PDP-11 Unix reported
if the code executed an IOT instruction (which was all that abort() did).
IOT was a trap instruction used by the aboriginal PDP-11 Paper Tape
Software in order to communicate with device drivers. Later DEC OSes used
EMT and Unix used TRAP, because the manual said it was for "user traps" and
Unix is a user operating system. At some point it seemed stupid to someone
to call the user-level routine abort() and the signal SIGIOT, and so added
SIGABRT as a synonym. Not really an answer, but that's all I have.
On Wed, Sep 1, 2021 at 10:24 AM Paul Winalski <paul.winalski(a)gmail.com>
wrote:
On 9/1/21, Dan Cross <crossd(a)gmail.com> wrote:
As an aside, I'd always been under the impression that the "AB" in
"ABEND"
comes from, "abnormal"?
You are correct, Dan. ABEND comes from the IBM (specifically
OS/360/370) world and is short for "abnormal end". It means that
application program (called the "problem program" in IBM mainframe
jargon) has terminated abnormally for some reason and control has
returned to the operating system. An ABEND was typically followed by
a core dump to the printer. As the manual for beginning programmers
at Boston College said, "Despite what your German teacher might tell
you, there is no such thing as a guten ABEND."
-Paul W.
9:59 p.m.
I disagree. TRAP according to the processor handbook was intended to be
used for what UNIX calls system calls. EMT was the emulator trap used
to simulate other operating systems on the same hardware. Oddly, for
some reason, all the DEC OSes use EMT instructions for their system
calls. This came in handy when JHU ported BasicPlus from RSTS to UNIX.
That executable could run fine on UNIX because we caught the few EMT
traps that mattered to us and simulated them. The only thing we had to
do other than that was to add a "nostack()" system call that got rid of
the normal UNIX-maintained stack starting at the address space (RSTS
executables like many DEC OSs used a stack that started around 1000).
Many of the UNIX signals come straight from PDP-11 traps: SIGFPE,
SIGIOT, SIGSEGV, SIGBUS, SIGILL, SIGEMT. and those traps invoked those
signals.
FPE - floating point exception
ILL - illegal exception (either unknown opcode or CERTAIN of the
privileged instructions, others were ignored)
BUS - fatal unibus timeout trap. Usually an attempt to access a
memory/unibus address that doesn't respond, or to do word accesses on
odd boundaries.
SEGV - accessing memory not mapped to you
IOT - the IOT instruction
BPT - the BPT instruction
TRAP, EMT - these instructions
2 Sep
2 Sep
12:09 a.m.
On Wed, Sep 1, 2021 at 10:07 AM Ron Natalie <ron(a)ronnatalie.com> wrote:
I disagree. TRAP according to the processor handbook
was intended to be
used for what UNIX calls system calls. EMT was the emulator trap used to
simulate other operating systems on the same hardware. Oddly, for some
reason, all the DEC OSes use EMT instructions for their system calls.
This came in handy when JHU ported BasicPlus from RSTS to UNIX. That
executable could run fine on UNIX because we caught the few EMT traps that
mattered to us and simulated them. The only thing we had to do other than
that was to add a "nostack()" system call that got rid of the normal
UNIX-maintained stack starting at the address space (RSTS executables like
many DEC OSs used a stack that started around 1000).
The various RT-11 emulators use variations on this theme as well, some
inside the kernel, some as a signal handler (fast forward 40-odd years and
I'm catching the SIGSEGV traps in executing 16-bit code to implement the
unix system calls)... It's a very useful and elegant trick that's been
oft-repeated.
Many of the UNIX signals come straight from PDP-11
traps: SIGFPE, SIGIOT,
SIGSEGV, SIGBUS, SIGILL, SIGEMT. and those traps invoked those signals.
Yes. They seemed to make perfect sense when I encountered them in Unix
after growing up on RSTS/e and RT-11 before my first contact with Unix....
FPE - floating point exception
ILL - illegal exception (either unknown opcode or CERTAIN of the
privileged instructions, others were ignored)
BUS - fatal unibus timeout trap. Usually an attempt to access a
memory/unibus address that doesn't respond, or to do word accesses on odd
boundaries.
SEGV - accessing memory not mapped to you
IOT - the IOT instruction
BPT - the BPT instruction
TRAP, EMT - these instructions
12:43 a.m.
On Wed, Sep 1, 2021 at 12:07 PM Ron Natalie <ron(a)ronnatalie.com> wrote:
I disagree. TRAP according to the processor handbook
was intended to be
used for what UNIX calls system calls. EMT was the emulator trap used to
simulate other operating systems on the same hardware.
The 1969 PDP-11 Handbook <
http://gordonbell.azurewebsites.net/digital/pdp%2011%20handbook%201969.pdf&…
says on p. 41 (PDF page 49): "[Trap] instructions provide for calls to
emulators, I/O monitors, debugging packages, and user-defined
interpreters", but it does not define "emulators". (The OED has several
citations for this sense of "emulator", but before about 1985 the context
seems to be hardware emulation only.)
Nevertheless, DOS/BATCH-11 (1970-71) already uses EMT as the system call
instruction, and it is clear that TRAP was for user use. At that point,
the only other operating system that could be emulated would be the Paper
Tape Software that I mentioned, which used IOT.
(BTW, RSTS/E's hypervisor would reflect any EMT instruction to the RTS (the
actual or emulated supervisor running in any given process, such as
Basic-Plus, RT-11, RSX-11, or Teco), with the exception of an EMT 377, EMT
377 sequence, which was a syscall to the hypervisor itself.)
1208
days inactive
1208
days old
7 comments
7 participants
participants (7)
-
Clem Cole -
Dan Cross -
John Cowan -
Paul Winalski -
Richard Salz -
Ron Natalie -
Warner Losh