Re: [Simh] Simulating the PDP-15/76 Unichannel
On 17 March 2015 at 23:01, Mark Pizzolato - Info Comm m...@infocomm.com wrote: Well, the intention of my suggestion was not to actually execute PIREX code in a PDP11 simulator, but to merely have the DR15 device implement the protocol (and the resulting behaviors) that the slave PDP11 system executed while running PIREX (that is what the RQDX3 simulator does when it implements MSCP). I'll say it's a good idea in theory, and great for just getting some semblance of the UC15 subsystem off the ground. But it creates software compatibility issues at best; and could cause complacency/stagnation of a correct implementation at worst. As Christian points out, the discussion in github issue (https://github.com/simh/simh/issues/96) covers this concept as mentioned by both Christian and Bob. I never read the detail of that issue since PDP-15 was way beyond/before my time and experience and the discussion seemed to have a good flow of its own (by most of the same folks involved in this one now). Just for those who don't want to read through the whole, rather long, discussion on GitHub, I'll summarize a few points regarding different ways of implementing just the UNICHANNEL-15: There's three ways, I see, of implementing it: 1. The Emulated solution Mark suggested: Emulating the functions of PIREX, and SPOL11 (we can't forget the spooler). -- Most user friendly of the ways of doing things, as the simulator would be pretty much the same as before and operate as it did normally; would probably resemble the current setup of the MASSBUS disk/tape and MASSBUS controllers on the PDP-11 simulator (device UC is the DR15 that is the Magical Device of PIREX and SPOL11Ⓡ; devices RK and LP11 are the RK05s and LP11 lineprinter). -- Probably going to be absolute hell to program. I mean, worse than trying to fit a stripped '11 simulator into the '15 simulator; you'll have to emulate the functions of both PIREX and SPOL11, and track their states during runtime. -- Not fully compatible with the software (can't load and run custom MACRO-11 programs from the PDP-15 end of things). 2. The Direct solution that Sergey suggested (and Bob discussed in the first e-mail): Cramming both emulators into one package. -- See what Bob said, regarding having to get the code to work. -- Still relatively user friendly; would probably need to add some fun extra boot routines: A cold start boot that brings up PIREX on the '11 and then boots the '15, a '15 only warm start, and an '11 only reload (for when PIREX/SPOL11/your-custom-application crashes it). -- Making the changes to the pdp11_cpu file to make it work will probably cause Much Fun™ with the standalone PDP-11 simulator; though you could also just for the CPU file, and strip it down to just being an 11/05 in function while making the needed variable name changes. -- Actually running this configuration will either mean making SIMH multithreaded (please do, I'd like to see SIMH get the ability to dink around the sim console as long as one pleases, without stopping the emulated CPU processing; just as the Hercules emulator does), or timeslicing/timesharing the execution (like the FPPs on the '8 and '15 work, if I presume correctly). 3. The Indirect solution that Johnny brought up (and which I personally think is the best one). -- Not as simple for the user to setup; then again the setup probably wouldn't be more complex than needed for HP2000 ACCESS on the HP21xx simulator. -- Greatest benefit to the SIMH project as a whole. -- Could be fun in terms of implementation in a way that keeps the cross-platform compatibility. Before, I used to be a proponent of the Direct approach, but I've been swayed to seeing the Indirect approach as the better option. I'm thinking that, to do the Indirect approach in the way that best allows for future interesting simulator escapades, that the memory sharing server be implemented on the PDP-11 and be made relatively generic. That is, it can share memory between another '11 simulator, a '15 simulator, and a theoretical future KL10 simulator. Meanwhile, there is a non-generic UC15 device, that connects to a similar UC15 device on the PDP-15, which operates as the UNICHANNEL configuration of DR11s and DR15. In the future a KL10 device, and IIST devices could be implemented, which would be the equivalent of the PDP-11 half of the KL10 front end interface, and the IIST of the PDP-11/74 (the IIST would also probably have to be implemented so that one server setup could connect up to three client IIST devices). I only foresee major problems with the above plan in both implementing the shared memory service in a generic manner, and the possibility of users doing insane things. Like hanging a PDP-15 off of a quad-CPU 11/74. (For SCIENCE! that must be done at one point. And equally, abusing PIREX and RSX-11/M+ to make that setup actually usable...) Also, the 11/74 and KL10 FE do some other interesting things that need be addressed as well. Just
Re: [Simh] Simulating the PDP-15/76 Unichannel
On 18 March 2015 at 00:03, Sergey Oboguev obog...@yahoo.com wrote: To clarify: I certainly did not suggest nor advocate it. True enough. Bob brought it up way back at the start of the thread. And he brought up the Indirect approach as well. You certainly did bring create an excellent posting on the pros and cons of the Direct approach. (Far better than I could explain anything...) Cheers, Christian -- Christian M. Gauger-Cosgrove STCKON08DS0 Contact information available upon request. ___ Simh mailing list Simh@trailing-edge.com http://mailman.trailing-edge.com/mailman/listinfo/simh
Re: [Simh] Simulating the PDP-15/76 Unichannel
From: E. Groenenberg qua...@xs4all.nl Any current reasonably seasoned Unix or derivative has shmat() shmdt() (or equivalent) calls for attaching detaching a segment of a given size. Also MS$ has this [...] so a common API for SIMH would be fairly easy. [ ...] With this feature, it would probably also easy to realize a PDP-11/74 with 4 instances of SIMH. Mapping shared memory segment into the address spaces of multiple SIMH instances is the straightforward part. More intricate parts are: 1) Mapping guest memory-consistency model to host memory-consistency model. Does legacy software expect to observe updates to the shared memory executed by simulated VCPU1 (or virtual IO processor) to become observable by VCPU2 in the same order they were executed by VCPU1? If yes, this would not work (without special handling by the simulator) on modern machines with weaker memory-consistency model. What is the cache coherency protocol of the simulated system and how does it map to the host system? Does simulated system have any system events (such as inter-processor interrupts or IO completion) that affect cache synchronization between VCPUs or VCPUs/VIOPs, and if yes, how this is to be mapped to the simulator? Ultimately it all depends on exact actual synchronization patterns utilized by legacy software. 2) Mapping memory atomicity. Does host machine provide the same memory access atomicity and separability as the simulated machine? For instance, if a simulated machine provides a way to update a byte at address A without interfering with concurrent updates to bytes at A-1 and A+1 by other VCPUs, then this would take a special effort to be implemented on a host machine that has let us say a 4-byte word as the minimum separable unit. Ditto for atomic and separable 2-byte word accesses (atomicity would mean that concurrent writes to the word do not result in resultant bytes values coming from different writes, separability would mean that concurrent writes to neighbor words do not interfere with each other). 3) Does a simulated system have any synchronization facilities such as interlocked instructions or machine-specific registers that affect cache coherency? 4) Mapping execution model. What happens if a host system thread simulating the execution of VCPU1 (or virtual IO processor) gets preempted, while VCPU2 is waiting for a response from VCPU1? Does the simulated system (specifically, its legacy software) rely on finite timeouts? ___ Simh mailing list Simh@trailing-edge.com http://mailman.trailing-edge.com/mailman/listinfo/simh
Re: [Simh] Simulating the PDP-15/76 Unichannel
On Tue, Mar 17, 2015 at 07:24:48PM -, Paul Hardy 2 wrote: The human brains ability to parse language is amazing. Without thinking I read that as: Your brain is a better language parser than mine is. I didn't very far attempting to decipher it. -- Kevin http://www.RawFedDogs.net http://www.Lassie.xyz http://www.WacoAgilityGroup.org Bruceville, TX What's the definition of a legacy system? One that works! Errare humanum est, ignoscere caninum. ___ Simh mailing list Simh@trailing-edge.com http://mailman.trailing-edge.com/mailman/listinfo/simh
Re: [Simh] Simulating the PDP-15/76 Unichannel
From: E. Groenenberg qua...@xs4all.nl Any current reasonably seasoned Unix or derivative has shmat() shmdt() (or equivalent) calls for attaching detaching a segment of a given size. Also MS$ has this [...] so a common API for SIMH would be fairly easy. [ ...] With this feature, it would probably also easy to realize a PDP-11/74 with 4 instances of SIMH. Mapping shared memory segment into the address spaces of multiple SIMH instances is the straightforward part. More intricate parts are: 1) Mapping guest memory-consistency model to host memory-consistency model. Does legacy software expect to observe updates to the shared memory executed by simulated VCPU1 (or virtual IO processor) to become observable by VCPU2 in the same order they were executed by VCPU1? If yes, this would not work (without special handling by the simulator) on modern machines with weaker memory-consistency model. What is the cache coherency protocol of the simulated system and how does it map to the host system? Does simulated system have any system events (such as inter-processor interrupts or IO completion) that affect cache synchronization between VCPUs or VCPUs/VIOPs, and if yes, how this is to be mapped to the simulator? Ultimately it all depends on exact actual synchronization patterns utilized by legacy software. 2) Mapping memory atomicity. Does host machine provide the same memory access atomicity and separability as the simulated machine? For instance, if a simulated machine provides a way to update a byte at address A without interfering with concurrent updates to bytes at A-1 and A+1 by other VCPUs, then this would take a special effort to be implemented on a host machine that has let us say a 4-byte word as the minimum separable unit. Ditto for atomic and separable 2-byte word accesses (atomicity would mean that concurrent writes to the word do not result in resultant bytes values coming from different writes, separability would mean that concurrent writes to neighbor words do not interfere with each other). 3) Does a simulated system have any synchronization facilities such as interlocked instructions or machine-specific registers that affect cache coherency? 4) Mapping execution model. What happens if a host system thread simulating the execution of VCPU1 (or virtual IO processor) gets preempted, while VCPU2 is waiting for a response from VCPU1? Does the simulated system (specifically, its legacy software) rely on finite timeouts? Sure, there are indeed other concerns. Concerning the mapping, this depends on how SIMH looks at host memory from a simulated system. If the memory is directly mapped, i.e. 1Mb of simulated system memory maps directly to 1Mb of host OS memory, it would be easier. If not, it indeed makes it more complex. Some form of messaging or synchronization would indeed be required, this could be done f.e. using msg calls (or equivalents), or use a dedicated small area in the shared memory segment for locking, using atomic locking instruction (i.e. xchgb instruction for x86 based processors or ldstub on sparc based processors) Ed -- Dit is een HTML vrije email / This is an HTML free email. Zeg NEE tegen de 'slimme' meter. ___ Simh mailing list Simh@trailing-edge.com http://mailman.trailing-edge.com/mailman/listinfo/simh
Re: [Simh] Simulating the PDP-15/76 Unichannel
On 17 March 2015 at 12:49, Phil Budne p...@ultimate.com wrote: Johnny Billquist wrote: There is a problem in that different emulators might use a different layout for memory, that you somehow need to overlap when you come here. And that layout can become rather weird, and how do you actually figure this out. If all simulated memory access is wrapped in C macros, you can hide most of the ugliness, assuming you don't mind a special build of the simulators for each multi-processor system. You might end up with four or more builds of the PDP-11 simulator: uniprocessor, 11-only multiprocessor, PDP-15 + PDP-11, PDP-10 + PDP-11. Since we have CPU cycles to throw away, a memory server process could solve the cache coherency problems... What of putting the memory server process into the PDP-11 simulator, and making it generic? That is, you could have the memory sharing service on the '11 simulator; which you could either configure as a the UC15, KL10 FE processor, or part of the 11/74. It's a more piece of software to program, but much more rewarding than compiling four different simulators, or writing four different new devices. Also, of note, I brought some of this up back in January 2014: https://github.com/simh/simh/issues/96 Also discussing implementing the card readers on the '15. Also, other multiprocessor systems that haven't been discussed that might be interesting to talk about are the multiprocessor KL10 systems namely the DECsystem-1088 and DECsystem-1099, the strange PDP-11/45+PDP-11/45 setup involving fun with UNIBUS B (not good at explaining things, E-11 does it as one of its unsupported configurations), and the dual-processor PDP-15 setup (two PDP-15 CPUs and optionally an FPP connected to one MX15-B). And while we're on the topic of interprocessor/interemulator communications, has anyone thought of perhaps implementing the DX11 with the co-operation of the Hercules team? It might be interesting to see what strange things could be done having the SIMH PDP-11 as a peripheral to a System/370, or System/390. -- Christian -- Christian M. Gauger-Cosgrove STCKON08DS0 Contact information available upon request. ___ Simh mailing list Simh@trailing-edge.com http://mailman.trailing-edge.com/mailman/listinfo/simh
Re: [Simh] Simulating the PDP-15/76 Unichannel
On 17 March 2015 at 21:41, Mark Pizzolato - Info Comm m...@infocomm.com wrote: Wasn't the RQDX3's processor a member of the PDP11 family? We don't try to execute the RQDX3 firmware, but we merely have a device simulator that communicates across the bus just as the RQDX3 did. Would an approach make sense that implemented the PIREX behaviors in a DR15 simulation (possibly, internally talking to the various UNIBUS device simulations)? Just a wild idea... I mentioned that back on the GitHub discussion (just to plug it again: https://github.com/simh/simh/issues/96). The PDP-11 side of things does more than just run PIREX and respond to requests. The PDP-11 also runs the SPOL11 spooler package, and you can run custom MACRO-11 programs on the '11 loaded and started by the '15. Really the best way is to find some way of making the simulators talk to each other. Plus, that framework can be expanded towards other examples. (KL10 and PDP-11/74, being the ones off the top of my head.) Regards, Christian -- Christian M. Gauger-Cosgrove STCKON08DS0 Contact information available upon request. ___ Simh mailing list Simh@trailing-edge.com http://mailman.trailing-edge.com/mailman/listinfo/simh
Re: [Simh] Simulating the PDP-15/76 Unichannel
Unless I misread Mark's message about the RQDX3 analogy, he is suggesting to put PDP-15 and PDP-11 in the same SIMH thread and in the same address space. When PDP-11 side becomes non-idle, it can signal an event and become eligible for execution, in a way similar to RQDX3. The options for co-execution with PDP-15 side in this structure are: 1) Execute PDP-11 exclusively until it enters idle state, then resume PDP-15 execution until PDP-11 becomes non-idle again.(This directly mirrors RQDX3 analogy). 2) Probably a better option (albeit dissimilar with RQDX3): co-execute PDP-11 and PDP-15 instruction streams on the same SIMH thread. I.e. execute of chunk of N instructions on PDP-15 side, then execute N (or M) instructions on PDP-11 side, then come back to PDP-15 main loop etc., and repeat this alternating execution of per-CPU main loops until one of the sides becomes idle, at which point the other side receives 100% share unless it becomes idle too. One disadvantage of this approach is namespace conflicts. But perhaps this can be addressed by restructuring SIMH build into machine-independent part and machine-specific parts, with machine-specific parts going to respective machine-specific DLLs/DSOs, with names local to specific CPUs not exported from these DLLs/DSOs and thus not colliding. A complication might be that while machine-independent part code may be shared, but some machine-independent data perhaps might be not (for instance the event queue may have the same logical structure for both sides, but either a separate instance of this structure is needed for each side, or resets etc. need to be handled in a more delicate and involved way taking into account which side is resetting -- so the required reorg may be deeper than at the first glance). The other disadvantage is that it does not leverage host multi-CPU resources. That's assuming computational performance matters at all. Yet the other disadvantage is the issues with calibrating VCPU speed. As the calibration now becomes significantly distorted by the co-executing CPU(s) going in and out of idle state in a rapidly varying pattern. Yet another disadvantage is that by default the consoles of two systems get mapped to the same host window, rather than being split, as they probably were in real life. Yet another disadvantage is a complication of the codebase to implement the mentioned reorgs or offset for them. The advantage is that it takes inter-thread synchronization issues out, includingmemory coherence issues and timing issues. But those may be not that great after all. - Original Message - From: Christian Gauger-Cosgrove captainkirk...@gmail.com To: Mark Pizzolato - Info Comm m...@infocomm.com Cc: simh@trailing-edge.com simh@trailing-edge.com Sent: Tuesday, March 17, 2015 6:58 PM Subject: Re: [Simh] Simulating the PDP-15/76 Unichannel On 17 March 2015 at 21:41, Mark Pizzolato - Info Comm m...@infocomm.com wrote: Wasn't the RQDX3's processor a member of the PDP11 family? We don't try to execute the RQDX3 firmware, but we merely have a device simulator that communicates across the bus just as the RQDX3 did. Would an approach make sense that implemented the PIREX behaviors in a DR15 simulation (possibly, internally talking to the various UNIBUS device simulations)? Just a wild idea... I mentioned that back on the GitHub discussion (just to plug it again: https://github.com/simh/simh/issues/96). The PDP-11 side of things does more than just run PIREX and respond to requests. The PDP-11 also runs the SPOL11 spooler package, and you can run custom MACRO-11 programs on the '11 loaded and started by the '15. Really the best way is to find some way of making the simulators talk to each other. Plus, that framework can be expanded towards other examples. (KL10 and PDP-11/74, being the ones off the top of my head.) Regards, Christian -- Christian M. Gauger-Cosgrove STCKON08DS0 Contact information available upon request. ___ Simh mailing list Simh@trailing-edge.com http://mailman.trailing-edge.com/mailman/listinfo/simh ___ Simh mailing list Simh@trailing-edge.com http://mailman.trailing-edge.com/mailman/listinfo/simh
Re: [Simh] Simulating the PDP-15/76 Unichannel
On Tuesday, March 17, 2015 at 7:50 PM, Sergey Oboguev wrote: Unless I misread Mark's message about the RQDX3 analogy, he is suggesting to put PDP-15 and PDP-11 in the same SIMH thread and in the same address space. When PDP-11 side becomes non-idle, it can signal an event and become eligible for execution, in a way similar to RQDX3. The options for co- execution with PDP-15 side in this structure are: Well, the intention of my suggestion was not to actually execute PIREX code in a PDP11 simulator, but to merely have the DR15 device implement the protocol (and the resulting behaviors) that the slave PDP11 system executed while running PIREX (that is what the RQDX3 simulator does when it implements MSCP). As Christian points out, the discussion in github issue (https://github.com/simh/simh/issues/96) covers this concept as mentioned by both Christian and Bob. I never read the detail of that issue since PDP-15 was way beyond/before my time and experience and the discussion seemed to have a good flow of its own (by most of the same folks involved in this one now). 1) Execute PDP-11 exclusively until it enters idle state, then resume PDP-15 execution until PDP-11 becomes non-idle again.(This directly mirrors RQDX3 analogy). 2) Probably a better option (albeit dissimilar with RQDX3): co-execute PDP-11 and PDP-15 instruction streams on the same SIMH thread. I.e. execute of chunk of N instructions on PDP-15 side, then execute N (or M) instructions on PDP-11 side, then come back to PDP-15 main loop etc., and repeat this alternating execution of per-CPU main loops until one of the sides becomes idle, at which point the other side receives 100% share unless it becomes idle too. Some aspect of this idea is also explored in that github issue... - Mark ___ Simh mailing list Simh@trailing-edge.com http://mailman.trailing-edge.com/mailman/listinfo/simh
Re: [Simh] Simulating the PDP-15/76 Unichannel
I was just going to ask questions which you answered below. As long as you've got things running in separate processes, there are no name collisions since they are separate simulator instances. You'll certainly need a memory reference paradigm which is more complicated than merely referencing the array M since there will be two blocks of memory (non-shared and shared). Other simulators already have separate address ranges which map to different things (VAX RAM, ROM, Qbus memory, etc...). Given the High Level synchronization operations (through the DR15/DR11) it won't be hard to assure memory coherency. Since your development platform is Windows, we can come up with a simple API to create a shared memory window and we'll worry about porting to other platforms later. OR YOU CAN STEP BACK and look at the problem differently: From the model you have describe it seems that the PDP-11 side is merely a slave to the activities on the PDP-15 side. Wasn't the RQDX3's processor a member of the PDP11 family? We don't try to execute the RQDX3 firmware, but we merely have a device simulator that communicates across the bus just as the RQDX3 did. Would an approach make sense that implemented the PIREX behaviors in a DR15 simulation (possibly, internally talking to the various UNIBUS device simulations)? Just a wild idea... - Mark On Tuesday, March 17, 2015 at 1:33 PM, Bob Supnik wrote: Memory semantics on the 15/76 were very simple. Neither machine had cache; neither machine had overlapped instruction execution; and neither system had locking capabilities. Therefore, the only ordering constraint is this: - all memory writes in common memory must be visible (committed) before either system issues an IO instruction to the DR15 or DR11 (which pokes the other system). That's because the ordering is based on the following software model: PDP15: - set up Task Control Block, set up buffers, pointers, etc. - write TCB address to the PDP11 via the DR15. At the point the TCB address is written, everything written to common memory must be visible to the PDP11. PDP11: - process TCB, do IO (either DMA or programmed IO) - post an IO completion interrupt back to the PDP15 via the DR11. At the point the interrupt is posted, everything written to common (or PDP15 non-common) memory must be visible to the PDP15. For a mashed up implementation, I don't think the memory container size difference is insurmountable. The PDP11 already abstracts memory access to routines like Read/Write or Map_Read/Write. These can be conditionally compiled as needed. The RK11 likewise would require relatively little work, mostly in abstracting the data type used for rkxb, the transfer buffer. As I said, the real problem is the global name space conflict. I didn't write the code with the expectation of mashups, so every simulator has a global M for memory, a global PC for the program counter. Because of code cloning, there tend to be lots of subroutines with the same names in every simulator. It's not insurmountable, because very little of the PDP11 is needed, but it's tedious and painstaking, and I don't want to end up having to retest the PDP-11 from scratch. That's why I ended up with five separate DECtape implementations rather than give skeletons and a common device library - it was easier at the time to clone and modify than to conditionalize. /Bob ___ Simh mailing list Simh@trailing-edge.com http://mailman.trailing-edge.com/mailman/listinfo/simh
Re: [Simh] Simulating the PDP-15/76 Unichannel
No. All Unibus IO is initiated by PIREX, the 11 IO executive. It is transferred, byte-by-byte or word-by-word, to/from buffers in the common shared memory. So, for example, to print to the LP11: 1) PDP-15 sets up a properly formatted 8b byte-packed buffer in common memory. 2) PDP-15 sets up a task control block (TCB) to print the buffer. The TCB is also in common memory. 3) PDP-15 pokes the PDP-11 via the DR15-C, passing in the address of the TCB. 4) PDP-11 invokes the LP11 task in PIREX, which pulls data from the buffer and sends it to the printer. 5) At completion, the PDP-11 posts an API interrupt back to the PDP-15 via one of the two DR11-C's. /Bob On 3/17/2015 11:42 AM, Mark Pizzolato - Info Comm wrote: On Monday, March 16, 2015 at 2:19 PM, Bob Supnik 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. Clearly the DR15/11 paradigm passing through PIREX is necessary for DMA devices, but how is programmed I/O handled. With the whole Unibus space addressable from the 15 side, is there code on the 15 which actually does programmed I/O directly to the Unibus devices? If programmed I/O is done directly by the 15, then this whole problem is very different than one which relates to shared memory access. - Mark ___ Simh mailing list Simh@trailing-edge.com http://mailman.trailing-edge.com/mailman/listinfo/simh
Re: [Simh] Simulating the PDP-15/76 Unichannel
On Tue, Mar 17, 2015 at 5:25 AM, E. Groenenberg qua...@xs4all.nl wrote: Some form of messaging or synchronization would indeed be required, this could be done f.e. using msg calls (or equivalents), or use a dedicated small area in the shared memory segment for locking, using atomic locking instruction (i.e. xchgb instruction for x86 based processors or ldstub on sparc based processors) Ed, Exactly - its more than just the shared address space, you need messaging, sequencing, sync etc. - this is why I was suggesting that instead of reinventing an API for simh, using one that has already been worked and agree upon by the HPC community. Since HPC is all about performance, I would have a solid belief that not only will the primitives work, but they will offer some of the highest efficiency for the code. At the risk of sounds like a fan-boy for OpenSHMEM, it seems to me to be the best of the PGAS family (particularly since it's a library not a new language like Chapel or UPC). I would be surprised if it did not have all of the things that Bob desired/needs built-in. In fact, one of the recent additions to OpenSHMEM is the new counting puts API which is a distributed (and scalable) locking and synchronization scheme similar to the old eventcount scheme of Reed Kanodia for UP systems [ http://dl.acm.org/citation.cfm?id=359076]. The implementations of these primitives map well to the instructions level that you point out. That said, if you stay with strict POSIX API instead, I suspect between their shared memory and locking/semaphore primitives, you will be pretty close and i think you should get a solid level of portability. My two concerns that that strategy are how many of the OSs have actually implemented the POSIX primitives, and when they have, how good a job was done implementing them. Not that the HPC community is perfect, but they tend to have an incentive to get the performance aspect right. Clem ___ Simh mailing list Simh@trailing-edge.com http://mailman.trailing-edge.com/mailman/listinfo/simh
Re: [Simh] Simulating the PDP-15/76 Unichannel
The Unichannel 15 Overview manual in the Bitsavers collection has a pretty good description of everything for those wondering about the details. https://archive.org/details/bitsavers_decpdp15Un974_2578882 There's an additional component, the MX15-B memory multiplexer, which arbitrates memory access (15 wins for simultaneous requests, otherwise, first come, first serve) and implements byte read/write for the 11. The manual also shows the memory layout and how it maps on each system, as well as a lot of other details of operation. Tom ___ Simh mailing list Simh@trailing-edge.com http://mailman.trailing-edge.com/mailman/listinfo/simh
Re: [Simh] Simulating the PDP-15/76 Unichannel
Johnny Billquist wrote: There is a problem in that different emulators might use a different layout for memory, that you somehow need to overlap when you come here. And that layout can become rather weird, and how do you actually figure this out. If all simulated memory access is wrapped in C macros, you can hide most of the ugliness, assuming you don't mind a special build of the simulators for each multi-processor system. You might end up with four or more builds of the PDP-11 simulator: uniprocessor, 11-only multiprocessor, PDP-15 + PDP-11, PDP-10 + PDP-11. Since we have CPU cycles to throw away, a memory server process could solve the cache coherency problems... phil ___ Simh mailing list Simh@trailing-edge.com http://mailman.trailing-edge.com/mailman/listinfo/simh
