stack space mapping question

[Richard H. E. Smith II]

This is a little bit of obscure history of interest to pdp-11 users,
and slightly aged unix hackers.  You can skip out now if this isn't
your sort of thing.  Otherwise, please bear with the long quotes:

>>In article <21131 at arizona.UUCP> whm at arizona.UUCP (Bill Mitchell) asks:
>>whether stack pages grabbed while the stack is deep are ever reclaimed
>>by the system when the stack recedes.
>>
>>                   On 4.2 on Suns and Vaxes, the system does allow (based
>>on empirical studies rather than code examination) access to pages below
>>the sp as long as they were properly contained in the stack at some point
>>in time.  Is this implementation dependent or is this some sort of standard
>>Unix "feature"?

>In article <248 at cheviot.UUCP> robert at cheviot.UUCP (Robert Stroud) writes:
>I don't know about more recent versions of Unix, but this was a "feature"
>of the PDP-11 V7 implementation where I first met Unix. I used it to extend
>my data area beyond 56K without fear of a segmentation violation.
>
>The memory mapping hardware on this PDP-11 restricted you to 8 segments, each
>of which could address up to 8K in steps of 64 bytes - or something like that.
>Because Unix must always have a stack segment, you couldn't extend your memory
>(using sbrk) beyond 56K (or 8 - 1 segments).
>
>However, if you extended the stack segment to its full 8K by setting,
>de-referencing and then re-setting the stack pointer, and set your break
>to 56K, then the full 64K address space was addressable without any
>danger of segmentation violation, and you could sneak a few extra bytes...
>
>I wasn't particularly proud of this trick, but it got me out of a hole.
>If anyone else out there is still using PDP-11's(!), they may find it useful.

If the pdp-11 wasn't being used in its "separate instruction and data space"
mode, you could do something even stranger... you could hang it up completely.
I did this to UNIX[tm] V6 back at the University of Wisconsin, in '74 or '75.
The pdp-11/45 has a privileged instruction SPL, which was a NOP in user state
except that it would hold interupts for one instruction (oops! a microcode
bug!).  By carefully allocating data and stack, one could fill the entire
32Kword address space with SPL instructions, and lock up the cpu completely.
All of address space except one NOP would really annoy the other users, but
did (eventually) allow interrupts.  Either looked nice in the lights, too.

I don't believe that the 11/70 cpu or later cpus have this microcode bug.
I don't advise you to test it... you must reset from the front panel after
the crash... altho a really skilled sysadm can spot this loop, and patch
it out of existance from the switches... somehow, I imagine that anyone
still running an 11 has such.  (No, I'm not picking on you.  I write 11
software for a living.)

To do the trick, I believe that some strange balance of allocating stack
and brk() memory had to be used, because the kernel allocated stack to the
program in some multiple of 3(?) 32word hunks.

Now, who remembers the one-instruction core clear?

-- 
----------
Dick Smith						..ihnp4!wlcrjs!rhesmith