[TUHS] A language question

[TUHS] A language question

[Richard Salz]

[-- 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 --]

Re: [TUHS] A language question

[Dan Cross]

[-- 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 --]

Re: [TUHS] A language question

[Clem Cole]

[-- 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 --]

Re: [TUHS] A language question

[Paul Winalski]

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.

Re: [TUHS] A language question

[John Cowan]

[-- 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 --]

Re: [TUHS] A language question

[Ron Natalie]

[-- 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 --]

Re: [TUHS] A language question

[Warner Losh]

[-- 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 --]

Re: [TUHS] A language question

[John Cowan]

[-- 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 --]