* [TUHS] A language question @ 2021-09-01 13:23 Richard Salz 2021-09-01 13:28 ` Dan Cross 0 siblings, 1 reply; 8+ messages in thread From: Richard Salz @ 2021-09-01 13:23 UTC (permalink / raw) To: TUHS main list [-- Attachment #1: Type: text/plain, Size: 282 bytes --] 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. [-- Attachment #2: Type: text/html, Size: 343 bytes --] ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [TUHS] A language question 2021-09-01 13:23 [TUHS] A language question Richard Salz @ 2021-09-01 13:28 ` Dan Cross 2021-09-01 13:44 ` Clem Cole 2021-09-01 14:23 ` Paul Winalski 0 siblings, 2 replies; 8+ messages in thread From: Dan Cross @ 2021-09-01 13:28 UTC (permalink / raw) To: Richard Salz; +Cc: TUHS main list [-- Attachment #1: Type: text/plain, Size: 755 bytes --] On Wed, Sep 1, 2021 at 9:25 AM Richard Salz <rich.salz@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. [-- Attachment #2: Type: text/html, Size: 1218 bytes --] ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [TUHS] A language question 2021-09-01 13:28 ` Dan Cross @ 2021-09-01 13:44 ` Clem Cole 2021-09-01 14:23 ` Paul Winalski 1 sibling, 0 replies; 8+ messages in thread From: Clem Cole @ 2021-09-01 13:44 UTC (permalink / raw) To: Dan Cross; +Cc: TUHS main list [-- Attachment #1: Type: text/plain, Size: 784 bytes --] On Wed, Sep 1, 2021 at 9:29 AM Dan Cross <crossd@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. ᐧ [-- Attachment #2: Type: text/html, Size: 2478 bytes --] ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [TUHS] A language question 2021-09-01 13:28 ` Dan Cross 2021-09-01 13:44 ` Clem Cole @ 2021-09-01 14:23 ` Paul Winalski 2021-09-01 14:29 ` John Cowan 1 sibling, 1 reply; 8+ messages in thread From: Paul Winalski @ 2021-09-01 14:23 UTC (permalink / raw) To: Dan Cross; +Cc: TUHS main list On 9/1/21, Dan Cross <crossd@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. ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [TUHS] A language question 2021-09-01 14:23 ` Paul Winalski @ 2021-09-01 14:29 ` John Cowan 2021-09-01 15:59 ` Ron Natalie 0 siblings, 1 reply; 8+ messages in thread From: John Cowan @ 2021-09-01 14:29 UTC (permalink / raw) To: Paul Winalski; +Cc: TUHS main list [-- Attachment #1: Type: text/plain, Size: 1378 bytes --] 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@gmail.com> wrote: > On 9/1/21, Dan Cross <crossd@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. > [-- Attachment #2: Type: text/html, Size: 1951 bytes --] ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [TUHS] A language question 2021-09-01 14:29 ` John Cowan @ 2021-09-01 15:59 ` Ron Natalie 2021-09-01 18:09 ` Warner Losh 2021-09-01 18:43 ` John Cowan 0 siblings, 2 replies; 8+ messages in thread From: Ron Natalie @ 2021-09-01 15:59 UTC (permalink / raw) To: TUHS main list [-- Attachment #1: Type: text/plain, Size: 1324 bytes --] 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 [-- Attachment #2: Type: text/html, Size: 2218 bytes --] ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [TUHS] A language question 2021-09-01 15:59 ` Ron Natalie @ 2021-09-01 18:09 ` Warner Losh 2021-09-01 18:43 ` John Cowan 1 sibling, 0 replies; 8+ messages in thread From: Warner Losh @ 2021-09-01 18:09 UTC (permalink / raw) To: Ron Natalie; +Cc: TUHS main list [-- Attachment #1: Type: text/plain, Size: 1862 bytes --] On Wed, Sep 1, 2021 at 10:07 AM Ron Natalie <ron@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 > > [-- Attachment #2: Type: text/html, Size: 2635 bytes --] ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [TUHS] A language question 2021-09-01 15:59 ` Ron Natalie 2021-09-01 18:09 ` Warner Losh @ 2021-09-01 18:43 ` John Cowan 1 sibling, 0 replies; 8+ messages in thread From: John Cowan @ 2021-09-01 18:43 UTC (permalink / raw) To: Ron Natalie; +Cc: TUHS main list [-- Attachment #1: Type: text/plain, Size: 1258 bytes --] On Wed, Sep 1, 2021 at 12:07 PM Ron Natalie <ron@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.) [-- Attachment #2: Type: text/html, Size: 2344 bytes --] ^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2021-09-01 18:44 UTC | newest] Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2021-09-01 13:23 [TUHS] A language question Richard Salz 2021-09-01 13:28 ` Dan Cross 2021-09-01 13:44 ` Clem Cole 2021-09-01 14:23 ` Paul Winalski 2021-09-01 14:29 ` John Cowan 2021-09-01 15:59 ` Ron Natalie 2021-09-01 18:09 ` Warner Losh 2021-09-01 18:43 ` John Cowan
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).