[Simh] Simulating the PDP-15/76 Unichannel

[Clem cole]

Unix at least three shared memory API's the old Columbus Unix shmem(which came out in the ATT stream - a lot of Unix have it but it's messy), the tenex mmap scheme (BSD's - which is cleaner and fewer side effects IMO) and eventually posix defined one that is suppose to be better still (but I don't know of a major ISV that uses it).  


The good news is that  I can't think of a modern Unix that does not support at least one of them.  Windows supports the first two in SFU in fact (which has a new name which I forget) and probably has the posix one also. There is supposed to be something like the old VMS shared memory API in Win32 but I've never messed with it - while I have used SFU. 

There is another SHMEM API which Cray defined in the mid 80's for PGAS style programming and has little in common with the old AT&T scheme other than name.  It has a different syntax and semantics.  This lives today as the OpenSHMEM project and as mostly syntax complainant although semantically there are still some rough edges. In fact the OpenSHMEM folks just released a new version of the spec which is being ratified this week. I fear that is only Linux and the high end HPC systems support it but it probably had the richest interface and would be both performant and functional.  

We can talk off list if you want some of the nitty gritty of the differences.  I suspect the answer is to define an API that works well for simh and then we can figure out how to implement it for each target OS.  Some OS will be able to have a choice of more than one so then it becomes a performance / operational choice. 

Sent from my iPhone

> On Mar 16, 2015, at 5:19 PM, Bob Supnik <bob at supnik.org> wrote:
> 
> This has been on the wish list for a decade.
> 
> The 15/76 Unichannel was a big PDP-15 that used a PDP-11/05 as an IO processor to get access to inexpensive Unibus peripherals, particularly the RK11-E/RK05, which supported 18b data, the LP11, the CR11, and various plotters (not supported in SimH). XVM/DOS and XVM/RSX supported the Unichannel, and standard DOS probably did as well.
> 
> The 15 and the 11 are crosscoupled through shared memory. Except for 4K-12K(W) of local memory, all of Unibus address space is mapped into the 15's main memory. DMA transfers from the RK11-E could transfer 18b data (using the Unibus parity lines for extra data lines); programmed IO transfers from the IO processor transferred 16b data, zeroing out bits 0-1 on the 15.
> 
> Control is done by a DR15-C parallel interface cross-connected to two DR11-C's in the 11. The 15 created task blocks in shared memory and transfers an 18b pointer to the 11 via the DR15/11 parallel connection. The 11's IO program, called PIREX, executes the directive and sends an API interrupt back when done.
> 
> Booting is awkward but didn't happen often; both machines had core memory that preserved program images.
> 
> The method for simulating multiple processors was demonstrated ten years ago, but it assumed a from-the-ground-up implementation. Mashing two simulator sources together creates serious global variable collisions that cannot be resolved without extensive edits to one or the other (probably the 11). This is why the HP 2100 Access dual system configuration is simulated on two separate simulator instances that communicate by TCP/IP. This is not practical for the 11/76 Unichannel, because of the shared memory.
> 
> Before I venture on a detailed design of a "merged" 15/11 simulator, I had one other thought. On today's multi-cores, it's perfectly practical to have two simulators running side-by-side, controlled from separate terminal windows. However, the two processes would need to share memory. Is there some simple way to do this on both Windows and Linux? I'm sure there's no portable solution.
> 
> /Bob
> _______________________________________________
> Simh mailing list
> Simh at trailing-edge.com
> http://mailman.trailing-edge.com/mailman/listinfo/simh