IOCTL or shared event for fast(frequently) communication

You continue to misunderstand and repeat incorrect info about the PDP-11 and SPL. Do not talk about things you
know nothing about, at least when there are folks who know better are within earshot.

Oh, come on…

I really hope that you are not going to argue against my assertion that PDP-11 prioritized interrupts to one another at the hardware level, right.

Although I haven’t had a chance to get any personal experience with PDP-11 (ironically, we are of the same age, i.e. “born in 1969”),
I am still in a position to get the publicly available documentation.

http://gordonbell.azurewebsites.net/digital/pdp%2011%20handbook%201969.pdf

This doc is pretty long, but here is a Wiki article that makes a reference to it, and this article happens to be much shorter

https://en.wikipedia.org/wiki/PDP-11

Here is the relevant excerpt from it

[begin quote]

The PDP-11 operated at a priority level from 0 through 7, declared by three bits in the Processor Status Word (PSW), and high-end models could operate in a choice of modes, Kernel (privileged), User (application), and sometimes Supervisor, according to two bits in the PSW.

To request an interrupt, a bus device would assert one of four common bus lines, BR4 through BR7, until the processor responded. Higher numbers indicated greater urgency, perhaps that data might be lost or a desired sector might rotate out of contact with the read/write heads unless the processor responded quickly. The printer’s readiness for another character was the lowest priority (BR4), as it would remain ready indefinitely. If the processor were operating at level 5, then BR6 and BR7 would be in order. If the processor were operating at 3 or lower, it would grant any interrupt; if at 7, it would grant none. Bus requests that were not granted were not lost but merely deferred. The device needing service would continue to assert its bus request.

Whenever an interrupt exceeded the processor’s priority level, the processor asserted the corresponding bus grant, BG4 through BG7. The bus-grant lines were not common lines but were a daisy chain: The input of each gate was the output of the previous gate in the chain. A gate was on each bus device, and a device physically closer to the processor was earlier in the daisy chain. If the device had made a request, then on sensing its bus-grant input, it could conclude it was in control of the bus, and did not pass the grant signal to the next device on the bus. If the device had not made a request, it propagated its bus-grant input to its bus-grant output, giving the next closest device the chance to reply. (If devices did not occupy adjacent slots to the processor board, “grant continuity cards” inserted into the empty slots propagated the bus-grant line.)

Once in control of the bus, the device dropped its bus request and placed on the bus the memory address of its two-word vector. The processor saved the program counter (PC) and PSW, entered Kernel mode, and loaded new values from the specified vector. For a device at BR6, the new PSW in its vector would typically specify 6 as the new processor priority, so the processor would honor more urgent requests (BR7) during the service routine, but defer requests of the same or lower priority. With the new PC, the processor jumped to the service routine for the interrupting device. That routine operated the device, at least removing the condition that caused the interrupt. The routine ended with the RTI (ReTurn from Interrupt) instruction, which restored PC and PSW as of just before the processor granted the interrupt.

If a bus request were made in error and no device responded to the bus grant, the processor timed out and performed a trap that would suggest bad hardware.

[end quote]

Anton Bassov

Have you so quickly forgotten the lessons I taught you?

OMG - it looks like, in actuality, I was not THAT wrong on that particular occasion.

Look at the following lines taken from the excerpt that I quoted in my previous post.

[begin quote]

Whenever an interrupt exceeded the processor’s priority level, the processor asserted the corresponding bus grant, BG4 through BG7. The bus-grant lines were not common lines but were a daisy chain: The input of each gate was the output of the previous gate in the chain. A gate was on each bus device, and a device physically closer to the processor was earlier in the daisy chain. If the device had made a request, then on sensing its bus-grant input, it could conclude it was in control of the bus, and did not pass the grant signal to the next device on the bus. If the device had not made a request, it propagated its bus-grant input to its bus-grant output, giving the next closest device the chance to reply. (If devices did not occupy adjacent slots to the processor board, “grant continuity cards” inserted into the empty slots propagated the bus-grant line.)

[end quote]

Anton Bassov

tl;dr (your posts above.)

Anton, stop it. You asserted in the previous thread (a) that the PDP-11 has a non-uniform cost for accessing hardware… which is false, and (b) that “the OS prioritising hardware interrupts to one another” was unique to the PDP-11, or done in software, or something… I’m honestly not sure WTF you’re saying. Interrupt priorities on the PDP-11 are a hardware concept, like they are on the IBM PC. They are reflected in the PSW, where the priority is set by either the SPL or MTPS instruction. Hardware interrupt priorities was not a new, or unique, concept to the PDP-11.

So, be quiet Anton. Contribute something useful to the questioners or go back to being quiet… as you have been for the past several months.

Your algorithm for being here should be:

if(AntonHasSomethingHelpfulForTheDIscussion()) {
    if(!ThisWillAnnoyPeter() {
        
        if(ThingToBePostedIsDefinitelyUseful()) {
            PostTheComment();   
        }
    }
}

Peter

I have to laugh when Anton starts talking about PDP-11’s. Until Windows the I had written drivers for PDP-11 OS’es (DOS, RT-11, RSX-11M, and Unix) than any other system, and I never thought about “interrupt priority”. I even worked on a few research OS’es on 11’s and never thought about the subject. I didn’t look at Anton’s references, I just grabbed my hardcopy of the PDP-11 manual from 1969.

Don Burn
Windows Driver Consulting
Website: http://www.windrvr.com

-----Original Message-----
From: Peter_Viscarola_(OSR) [mailto:osr+d292382-s6030753@vanillacommunity.email]
Sent: Monday, September 21, 2020 3:12 PM
To: Don_Burn burn@windrvr.com
Subject: Re: [NTDEV] IOCTL or shared event for fast(frequently) communication

OSR https://community.osr.com/

Peter_Viscarola_(OSR) commented on IOCTL or shared event for fast(frequently) communication

tl;dr (your posts above.)

It’s interesting that I missed the whole PDP-11 revolution. I went straight from mainframes to Windows. Now, when the conversation drifts over to the peripheral processors on Control Data Cyber machines, I’ll be ready.

the whole PDP-11 revolution

Ah, yes… The Minicomputer Revolution.

It was a pretty terrific learning-ground for OS development. One person could understand (and, er, write) the entire OS… and the OS source code (in assembly language) probably didn’t run to 500 printed pages.

And the assembly langue was MUCH easier than IBM BAL. hmmmm… Now, there’s a topic. JCL anyone?

Peter