[Simh] New simulator - VAX-11/782

[Sergey Oboguev]

Matt Burke <matt at 9track.net> wrote:

> I probably should have researched memory barriers a bit more. 
> I knew a little bit about them but wasn't sure if they were needed here. 
> The problem may also exist for the rest of the shared memory.

For the purposes of running VMS, what really and ultimately matters is not what actual 78x hardware does, but what VMS expects it to do. And this latter bit can be learned from VMS sources, even if we do not have (and may be unable to obtain) sufficient knowledge about the hardware. 

Precise understanding of VMS expectations would require a more thorough look into VMS sources than I could have until now, however my hunch is that VMS desires are a subset of a stronger general statement: 

[SS:] "When VCPU1 and VCPU2 [in a shared-memory or cache-coherent multiprocessor] communicate via an IPI from VCPU1 to VCPU2, VCPU1 [most often] wants to pass its view of memory to VCPU2".

VMS may quite possibly expect less than that, however we do not (yet) know exactly what... it might take a night or more with the listings to understand the code well enough to figure this out exactly. (Comments in the code next to BBSSI/BBCCI instructions suggest that VMS uses them purposefully to flush and control the cache "manually"... hence my questions in the previous message.)

Also this "less" might turn out to be more difficult to implement in practice than (both stronger but comparatively simpler) SS.

My *hunch* however is that if SS were in place, VMS will most likely be happy with it. There is a slim chance this might prove wrong, only code reading might tell, but I think this chance is pretty slim... I'd place money on it. Thus assuming it for now:

SS is easy to implement. There is a flag that CPU1 sets and CPU2 reads, to pass an IPI. If this flag is protected by a lock both on read and write sides, this would ensure SS, since locking primitives issue memory barriers (and compiler barriers as well -- another important thing to have in mind).

Right now ipc_send_int uses ipc_lock/ipc_unlock but ipc_poll_int does not. If ipc_poll_int used locking (matching one in ipc_send_int), that would provide memory barriers (along with compiler barriers) and provide SS.

Alternatively, it is possible to insert WMB (or full MB) primitive into ipc_send_int before setting an IPI flag, and insert a RMB (or full MB) primitive in ipc_poll_int after reading the flag, but these are platform-specific. (RMB and WMB designations here also imply compiler barrier included, on both sides of a hardware barrier). VAX MP out of necessity has an implementation for smp_rmb() and smp_wmb() that also include compiler barrier (barrier(), COMPILER_BARRIER), but you do not really want to get into this host platform specific (and for X86, also host CPU model specific and bitness specific) mess unless really necessary... and for 782 it is really not. Using locks is a much neater solution for 782 purposes, I think.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.trailing-edge.com/pipermail/simh/attachments/20170526/7d9828c4/attachment-0001.html>