[Simh] Simulating the PDP-15/76 Unichannel

[Clem Cole]

On Tue, Mar 17, 2015 at 5:25 AM, E. Groenenberg <quapla at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.trailing-edge.com/pipermail/simh/attachments/20150317/324203b1/attachment.html>