Thread by @JohnMashey

@Cloudflare SSV1/More to the SIGSEGV story.
UNIX 1970/71 was implemented on PDP-11/20s, which had no memory mapping of protection, although BTL research later got an 11/20 with the KS-11 mapping option:
bell-labs.com/usr/dmr/www/pi…
bell-labs.com/usr/dmr/www/od…

@Cloudflare SSV2/UNIX Third Edition apparently didn’t have signal(II)
bitsavers.org/pdf/att/unix/3… Unsurprisingly as few PDP-11/20s in Bell Labs would have had KS-11s.

@Cloudflare SSV3/Ken & Dennis got early PDP-11/45, which had real memory management, rewrote kernel in C, and signal was in 4th Edition, the one I started with in Fall 1973, ~same week as we got our 11/45 for PWB/UNIX. Sadly I’ve misplaced/lost that manual, but:
dspinellis.github.io/unix-v4man/v4m…

@Cloudflare SSV4/ Anyway, Signal 11* “segmentation violation” really came in with V4, which used 11/45 memory management (and later, 11/70, similar, but with expanded physical addressing). That’s:
bitsavers.org/www.computer.m…

@Cloudflare SSV5/Terminology is a bit confusing. On most systems, smallest page is smallest unit of allocation, but PDP-11/45’s 4K-word (8KB) “pages” were somewhat like “segments” in most others. They could grow (up for data, down for stack) until all 32-word units were used in 4KW.

@Cloudflare SSV6/In PDP-11s, stack grew downward from top of address space. I’m pretty sure UNIX V4 did as later. trapped memory accesses below and “near” top of stack, and automatically grew the stack downward.
stackoverflow.com/questions/3211…
Of course, this was not needed for brk(2).

@Cloudflare SSV7/However, quite famously, when Steve Bourne was doing Bourne shell, when allocating memory, he didn’t check for running over edge of heap, but caught SIGSEGV, did a brk and then reexecuted.
This worked on PDP-11, VAX and others, BUT
caused great grief on early 68K systems

@Cloudflare SSV8/Here’s the history, read the whole thing, including DMR’s comments at the end.
in-ulm.de/~mascheck/bour…
Computers could run faster if they didn't have to worry about exceptions & recovery from them :😃

@Cloudflare Oops lost

SSV6/In PDP-11s, stack grew downward from top of address space. I’m pretty sure UNIX V4 did as later. trapped memory accesses below and “near” top of stack, and automatically grew the stack downward.
stackoverflow.com/questions/3211…
Of course, this was not needed for brk(2).

@Cloudflare SSV9/ The problem with early 68K’s illustrates important interaction of computer architecture, operating systems & languages: when a non-fatal fault occurs that can invoke user-level handler, what’s the “contract” for expected behavior?
Can you fix & resume? Easily?

@Cloudflare SSV10/ For example, IBM 360/67s trapped stores to protected memory pages, but the resulting PC was “imprecise”, CPU cpukd have executed at least one more instruction before discovering the fault. IBM 360/91s (out-of-order speculative) also had imprecise exceptions.

@Cloudflare SSV11/ UNIX grew in PDP-11s, relatively simple sequential designs. As mini’s/micros got more aggressive pipelines/parallel/caches/complex MMUs, performance optimizations could lead to strange exception problems... that systems programmers would have to deal with, somehow.

@Cloudflare SSV12/ The 68K problem was mentioned & National Semi 32Ks had various bugs. The Intel i860 was infamous for complex exception handling. When we designing MIPS, I insisted that we get a clean Exception Program Counter, pointing at 1st instruction not yet completed, previous done.

@Cloudflare SSV13/ A particularly-exciting example was the Prisma P1 (a multichip GaAs SPARC). USENIX Proceedings Summer 1990 - see Mike O’Dell’s “Putting UNIX in Very Fast Computers”, pp.239-246.
Still a thoughtful analysis of assumptions/contracts with signal handlers on aggressive CPUs.

@Cloudflare SSV14/ Mike’s (spoken)conclusion: mothers, don’t let your children grow up to be operating systems programmers.
Great paper if you can find copy.

@Cloudflare SSV15/ I looked around to find Mike's paper online, couldn't find it, so I scanned my old markedup copy.
Some of the first part might be a little hardware-heavy, but anyone who works near the hardware-software interface should read this. pp.239-246

@Cloudflare SV16/ p.240

@Cloudflare SSV17/ p.241

@Cloudflare SSV18/ p.242

@Cloudflare SSV19/ p.243

@Cloudflare SSV20/ p.244

@Cloudflare SSV21/ p.245
If you are designing software tightly-coupled to highly-parallel/out-of-order hardware, think hard about this.

@Cloudflare SSV22/ p.246