Thanks for some additional information.
On 2016-03-28 18:16, Milo Velimirović wrote:
>
>> On Mar 28, 2016, at 9:44 AM, Johnny Billquist <bqt(a)update.uu.se> wrote:
>>
>> On 2016-03-28 16:18, Noel Chiappa wrote:
>>> > From: Dave Horsfall <dave(a)horsfall.org>
>>>
>
> [ Wait & RK discussion snipped.]
>
>>
>>
>>> > I know that Kevin Dawson (I think) tried it on my /40 as well
>>>
>>> The 11/40 does not have the SPL instruction; see the '75-'76 PDP-11 Processor
>>> Handbook, pg. 4-5. (Again, sorry, just want to be accurate.)
>>
>> This is also a pretty important point. But one which also begs the question how the splxxx() functions in Unix worked back then. Or did Unix not use this pattern and these functions back when the 11/40 was relevant?
>
> These functions existed in V6 and can be found in the file, m40.s, that was assembled with the rest of the kernel to generate a unix that would run on a /40 class machine.
Aha. Great. Thanks. Yes, BIS and BIC on the PSW obviously works, but
this would definitely not block interrupts for the next instruction. So
at least in that case, a WAIT could result in the kernel sitting around
waiting for the next interrupt. I don't really think DEC intend WAIT to
be used in the way Unix uses it, and it don't really have the properties
that would be ideas for Unix. Also somewhat indicated by the fact that
DEC did not use WAIT this way themselves.
Johnny
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: bqt(a)softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol
On 2016-03-27 23:49, jnc(a)mercury.lcs.mit.edu (Noel Chiappa) wrote:
>
> > 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?
Hmm. A good point. If you depend on WAIT waking you up at an interrupt,
then you need SPL to block here. But this also means that you must be at
SPL 7 before any of this, otherwise you are still exposed to this
problem (nothing says that the interrupt won't happen before the SPL as
well).
In general, I would say that this is not the way I would write code, but
checking in RSX and 2.11BSD I can tell that RSX do not use this pattern,
and does a WAIT without any SPL, while 2.11BSD do an SPL 0 followed by
WAIT. And the routine in 2.11BSD is also called at SPL 7.
So obviously, both ways have been done, and 2.11BSD will work
potentially with a slight degration if the SPL do not block interrupts.
It will still work fine, as you will, at a minimum, get an interrupt at
the next clock tick, which will wake it up. But it might possibly be
sitting in a WAIT slightly longer than required.
RSX in fact just loops after the WAIT. If an interrupt should cause the
system to be able to do something more productive, it will not return to
the idle loop. So yes, it also detects in the interrupt exit processing,
that it was/is in the idle loop.
I still haven't had time to investigate properly. But at least processor
and chip manuals do not say that SPL will block interrupts. But that is
no guarantee that it don't in reality.
Johnny
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: bqt(a)softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol
> From: Dave Horsfall <dave(a)horsfall.org>
> SPL 7 was only used by the clock interrupt
Err, according to the 1975 Peripherals Handbook, both are BR6. (Sorry, only
interested in accuracy.)
> even the published Unibus spec was known to be wrong, in order to keep
> 3rd-party kit out of it (it was something subtle to do with buss timing,
> so sometimes the card worked, and sometimes it didn't, doing wonders for
> your reputation).
I don't know about that, but we built two UNIBUS DMA networking devices,
relying on the UNIBUS description in the 1975 Peripherals Handbook, and they
both worked fine (one became a product for Proteon).
> Slightly longer? I think it was Lions himself who used to teach us that
> a lost interrupt is nasty :-(
The interrupt isn't lost, it's just that the OS does a WAIT when it should
perhaps return and start up some user process - but that resumption of doing
user computations is delayed by at most 1 clock tick (some other device may
interrupt during the WAIT, before the clock does).
> Anyone here remember overlapped seeks on the RK-11 failing under Unix
I'd be interested in the details of this. The V6 RK driver didn't use them,
but the RK11-D does claim to support them (having spent a modest amount of
time looking at the drawings), so I'd very much like to know what the bug was.
> I know that Kevin Dawson (I think) tried it on my /40 as well
The 11/40 does not have the SPL instruction; see the '75-'76 PDP-11 Processor
Handbook, pg. 4-5. (Again, sorry, just want to be accurate.)
> Christ, but this is starting to sound like some religion or other.
I am only interested in correct data.
Noel
> From: Johnny Billquist
> this also means that you must be at SPL 7 before any of this
Yes, I assumed that (since it wouldn't make sense otherwise :-).
> In general, I would say that this is not the way I would write code, but
> ... 2.11BSD do an SPL 0 followed by WAIT.
Right; even if one does something like have every interrupt set a flag (which
is cleared while interrupts are disabled), and check that after lowering the
priority, but before doing the WAIT, there's _still_ a window between that
check, and the WAIT (although I guess it's less likely to be hit, since the
interrupt request would have to be posted _in that window_, not be hanging
around waiting to be serviced).
The only way (that I can work out) to atomically lower the priority and wait
is to do an RTI with the PC on the stack pointing to the WAIT instruction, but
I'm not sure even that is guaranteed to work.
I guess it all depends on the CPU implementation: does it check for pending
interrupts before each instruction, or only at the end of each instuction, or
what? If before, and there's an interrupt pending, it will go off before the
WAIT is executed. Although I suppose if it's at the end, it would do the check
at the end of the RTI, and do the interrupt then.
And whether it's at the end, or the beginning, WAIT itself must be special
cased, to check for pending interrupts during the execution (which can take an
indeterminate amount of time).
> 2.11BSD will work potentially with a slight degration if the SPL do not
> block interrupts. It will still work fine, as you will, at a minimum,
> get an interrupt at the next clock tick, which will wake it up. But it
> might possibly be sitting in a WAIT slightly longer than required.
Yes, exactly.
> RSX in fact just loops after the WAIT. If an interrupt should cause the
> system to be able to do something more productive, it will not return to
> the idle loop. So yes, it also detects in the interrupt exit processing,
> that it was/is in the idle loop.
Does it detect if it was _before_ the WAIT instruction? I would assume it does,
but I don't know anything sbout RSX.
> But at least processor and chip manuals do not say that SPL will block
> interrupts.
Yes, I looked too, in a variety of places (PDP-11 Architecture, including in
the 'model differences' table, 11/73 Tech Manual, etc). Crickets...
Noel
> From: Warren Toomey
> I thought it would be nice to get a feel for what it was like to use a
> real tty
Make sure it only prints 10 characters per second, then. (I think TTY's were
10 cps?) R-e-a-l-l-y s-l-o-w.
Noel
On 2016-03-27 08:18, Greg 'groggy' Lehey<grog(a)lemis.com> wrote:
> Isn't it wonderful that we no longer have issues with character
> representation?
I hope that comment was meant as a joke, ironic, cynical, or whatever...
Johnny
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: bqt(a)softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol
> 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
On 2016-03-27 03:50, Dave Horsfall<dave(a)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(a)softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol
As attached, thanks to someone over on the RTTY list; not sure if it's
exactly what he wanted.
--
Dave Horsfall DTM (VK2KFU) "Those who don't understand security will suffer."
---------- Forwarded message ----------
Date: Sat, 26 Mar 2016 18:52:59 -0700
From: tony.podrasky
To: Dave Horsfall <dave(a)horsfall.org>
Subject: Re: [GreenKeys] Teletype simulator? (fwd)
Hi Dave;
Attached is my TTY test program.
It is fairly simple. The only thing that might be
tricky is the type of UAR/T you are using.
Let me know if it compiles.
regards,
tony
On 03/26/2016 06:33 PM, Dave Horsfall wrote:
> On Fri, 25 Mar 2016, tony.podrasky wrote:
>
> > What do you mean, "a non-Windoze" TTY simulator?
>
> One that's in source form, not binary...
>
> > One of the programs I have takes e-mail and prints it on a 5-level ITA#2
> > machine.
> >
> > It is written in "C", and at such a low-level that it should compile on
> > ANY thing that runs "C".
>
> Got a copy you can send me to pass on?
>
--
"I read somewhere that 77 percent of all the
mentally ill live in poverty. Actually, I'm more
intrigued by the 23 per cent who are apparently
doing quite well for themselves." -Jerry Garcia
On 2016-03-24 03:00, "Ron Natalie"<ron(a)ronnatalie.com> wrote:
>
>> >Closest I've ever been murdered was when I "accidentally" filled the local
>> >11/70 with an uninterruptible instruction sequence."
> SPL instruction. The PDP-11 was odd that while SPL was a "privileged"
> instruction, rather that trapping if you did it in user mode, it just
> "ignored" it.
> Well, what it ignored was the actual change of the processor level. What
> it still implemented was the side effect was that interrupts were locked out
> until the next instruction fetch.
> If you filled your instruction space up with SPLs you could lock up the
> computer so that even the HALT key didn't work (you had to do a bus RESET).
Ok. Color me stupid, but I don't get it. I totally do not understand how
this locks anything out.
It is the normal behavior of any instruction that interrupts are not
recognized until the next instruction fetch. This is how the microcode
works, and it is also pretty much the same in any processor today.
Except for instructions that take a long time, and which can be
interrupted in the middle, the context preserved, and the instruction
restarted and continued, instructions are normally atomic. You cannot
get interrupts in the middle of an instruction.
Second, I cannot understand how filling the memory with SPL instructions
(or any other instruction) can lock out the CPU. As noted, they are
individual instructions. You still get a fetch between each instruction,
at which point, interrupts will be recognized.
Now, if you instead talked about actually raising the CPU to SPL 7, then
I agree that no interrupts will happen. But that is because you
essentially disabled interrupts.
The front panel still works though. It is not handled like an interrupt,
but it is true that it do interact with the processor states, and
normally if you pull HALT, it will only halt when it's going to fetch
the next instruction. You can, of course, also set the front panel
switch for single microcode instruction, at which point the CPU will
halt at the next microcode instruction instead, and you can single step
the microcode as well.
The one CPU I know you can sunset is the KA10 (PDP-10). I'm sure there
are others, but I have never seen how this could be done on a PDP-11, so
I'm most curious about this, and if you can provide more details I would
be most interested. As I also happen to know where a PDP-11/70 is
standing, I intend to test this out next I get close to it.
As for the KA10 (I think it was the KA10, but it might have been the
PDP-6), the problem is related to the indirect addressing feature. Since
memory is 36 bits, but addresses only 18, you have plenty of bits to
play with. And one of them is the indirect bit. And if you refer to a
memory location that also have the indirect bit set, you get another
memory access to get the actual content. The fun thing happens if you
set the indirect bit, and give your own address. This is then an
infinite memory reference. And the KA10 can not be broken out of that
lookup. The only solution is to pull the power plug.
The CPU is essentially stuck in one state, just tightly reading memory,
and then repeating reading memory. Later PDP-10 models have an explicit
check in the microcode in this loop to be able to break out of this.
Sorry for the offtopic content. :-)
Johnny
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: bqt(a)softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol