[TUHS] PDP-11/70 SPL (was: Early non-Unix filesystems?)

[TUHS] PDP-11/70 SPL (was: Early non-Unix filesystems?)

[Noel Chiappa]

    > From: Johnny Billquist

    > It would also be interesting if anyone can come up with a good reason
    > why SPL should work that way.

So that when doing:

	SPL	0
	WAIT

you don't lose by having the interrupt happen between the SPL and the WAIT?

	Noel

[TUHS] PDP-11/70 SPL (was: Early non-Unix filesystems?)

[Dave Horsfall]

On Sun, 27 Mar 2016, Noel Chiappa wrote:

>     > why SPL should work that way.
> 
> So that when doing:
> 
> 	SPL	0
> 	WAIT
> 
> you don't lose by having the interrupt happen between the SPL and the WAIT?

That makes sense, and someone forgot to document it...

-- 
Dave Horsfall DTM (VK2KFU)  "Those who don't understand security will suffer."

[TUHS] PDP-11/70 SPL (was: Early non-Unix filesystems?)

[Noel Chiappa]

    > From: Dave Horsfall

    > That makes sense, and someone forgot to document it...

Or perhaps it was added precisely to get rid of the window, and then someone
discovered that it could be used to freeze the system, so they decided they'd
better not document it?

If the system had MOS memory, and you had to power cycle the machine to get it
out of this state, there wouldn't be any evidence left of who did the deed
(unless the system was writing extensive audit trailing to disk), so it would
be a great 'system assasin' (aka vandal) tool.

	Noel

PS: I guess this is more PDP-11ish than UNIXish - apologies for the off-topic!

[TUHS] PDP-11/70 SPL (was: Early non-Unix filesystems?)

[William Pechter]

The 11/70 with Mr memory had battery backup on the MOS usually so they would have the saved memory content unless they powered off the battery backup. 


Sent from my android device.

-----Original Message-----
From: Noel Chiappa <jnc@mercury.lcs.mit.edu>
To: tuhs at tuhs.org
Cc: jnc at mercury.lcs.mit.edu
Sent: Mon, 28 Mar 2016 10:18
Subject: Re: [TUHS] PDP-11/70 SPL (was: Early non-Unix filesystems?)

    > From: Dave Horsfall

    > That makes sense, and someone forgot to document it...

Or perhaps it was added precisely to get rid of the window, and then someone
discovered that it could be used to freeze the system, so they decided they'd
better not document it?

If the system had MOS memory, and you had to power cycle the machine to get it
out of this state, there wouldn't be any evidence left of who did the deed
(unless the system was writing extensive audit trailing to disk), so it would
be a great 'system assasin' (aka vandal) tool.

	Noel

PS: I guess this is more PDP-11ish than UNIXish - apologies for the off-topic!

[TUHS] PDP-11/70 SPL (was: Early non-Unix filesystems?)

[Dave Horsfall]

On Mon, 28 Mar 2016, Noel Chiappa wrote:

>     > That makes sense, and someone forgot to document it...
> 
> Or perhaps it was added precisely to get rid of the window, and then 
> someone discovered that it could be used to freeze the system, so they 
> decided they'd better not document it?

Yeah, I've pretty much concluded that.  I'm still wondering how it leaked 
out, though.

[...]

> PS: I guess this is more PDP-11ish than UNIXish - apologies for the 
> off-topic!

Ah, grasshopper, you do not know that this list's predecessor was PUPS 
(PDP-11 Unix Preservation Society)...  It was first mentioned over on the 
old AUUG list.

-- 
Dave Horsfall DTM (VK2KFU)  "Those who don't understand security will suffer."

[TUHS] PDP-11/70 SPL (was: Early non-Unix filesystems?)

[Johnny Billquist]

On 2016-03-27 03:50, Dave Horsfall<dave at horsfall.org> wrote:
>
> On Fri, 25 Mar 2016, Johnny Billquist wrote:
>
>>> > >Some instructions inhibit the "check for interrupts at the end of this
>>> > >instruction" check.  I'm most familiar with the 8080 EI instruction,
>>> > >which enabled interrupts after the following instruction (so things
>>> > >like EI;HLT didn't have a window).  It seems the PDP-11 SPL behaves
>>> > >the same.
>> >
>> >I don't think it should on the PDP-11, and the documentation do not
>> >mention any such thing.
> It most certainly did, at least on the 11/70 that I used...  Do you have
> experience otherwise?

I do not have any experience either way. I have never checked this. I'm 
just saying that it don't make sense in my head, and the processor 
handbook do not describe such a property of SPL. But now that I know, 
I'm going to try and find out.

It might be correct. I'm just surprised if so, since there is no 
technical need for SPL to act that way. And having SPL behave 
differently than all other instructions means extra work for the people 
who wrote the microcode.

It would also be interesting if anyone can come up with a good reason 
why SPL should work that way.

	Johnny

-- 
Johnny Billquist                  || "I'm on a bus
                                   ||  on a psychedelic trip
email: bqt at softjar.se             ||  Reading murder books
pdp is alive!                     ||  tryin' to stay hip" - B. Idol

[TUHS] PDP-11/70 SPL (was: Early non-Unix filesystems?)

[Dave Horsfall]

On Sun, 27 Mar 2016, Johnny Billquist wrote:

> I do not have any experience either way. I have never checked this. I'm 
> just saying that it don't make sense in my head, and the processor 
> handbook do not describe such a property of SPL. But now that I know, 
> I'm going to try and find out.

I'll say it again: it's *definitely* how SPL worked (at least, on the 
11/70 that I hung; too many witnesses...).  Somewhere Out There (tm) is a 
little self-relocating program that completely filled user memory with SPL 
(including overwriting itself; the last act it did was to overwrite 
itself, and was sheer genius).  I saw it in a ;login: newsletter, so it 
*might* be in AUUGN...  When the PC wrapped around, it was SPLs all the 
way down :-)

> It would also be interesting if anyone can come up with a good reason 
> why SPL should work that way.

Likely a firmware bug?

-- 
Dave Horsfall DTM (VK2KFU)  "Those who don't understand security will suffer."