Re: Question on T9000

[Larry Dickson <tjoccam@xxxxxxxxxxx>]

Roger, David, and Uwe,

Thank you! I did look at the instruction set manual, and the description of the protection scheme is very clear (I’m still looking for such good descriptions in the case of the x86 and the ARM). It seems that the so-called “stub” could do the job, but the question of legality would still exist - if one was serious about the protection being maintained. It seems that the “logical” addresses talked about there are the same as “virtual” addresses in x86 etc, or am I assuming too much? Are there page tables?

David, wouldn’t it be true that any channel accessed by occam would be compiler-checkable to be legal? Could C index into a list maintained by the stub? Thanks for bringing this up, because I was focusing on the source and target data arrays. I’m wondering if pages might be swapped out, and/or if the earlier communication might check out OK and then the later process find that its side violates memory protection.

Larry

On Dec 23, 2016, at 2:46 AM, David May <dave@xxxxxxxxxxxxxxxxxxxxx> wrote:

As far as I remember, the problem is the channel addresses. Every P-process would need a set of the channel addresses it is allowed to use. These would need to be checked on every communication. 

David

On 22 December 2016 at 21:21, Larry Dickson <tjoccam@xxxxxxxxxxx> wrote:

Hello all,

I don’t know who to address this to, so I will ask you all. Is there someone out there who worked on the T9000 protected mode system?

I picked up a copy of "THE T9000 TRANSPUTER HARDWARE REFERENCE MANUAL” at

http://www.transputer.net/ibooks/72-trn-238-01/t9000hrm.pdf

and looked at the communication instructions in, out, etc. (p 95). They were all marked P (Instruction not allowed in P-process). By contrast, move was marked M (Invalid memory-address for P-process), as were ldnl, stl, stnl, etc. Thus, the latter are legal given good addresses, and the former are not legal even if addresses are good, despite the famous CSP equivalence of

b := a

and 

chan c :

PAR

  c ! a

  c ? b

Why are the communications illegal? Was it because only one "current process” is allowed, or was it too hard to keep control over virtual memory while waiting for the second process, or was development effort too great for something which does not exist in C-language user-space? Was communication off-loaded to the L-process belonging to that P-process, or was it just not modeled?

By the way, thank you everyone who helped me to a copy of Michael Poole’s ETC paper in WoTUG-21. The book arrived, and has several other treasures besides ETC. For instance, “An optimizing multiprocessor occam system for the PowerPC” has true interrupt-level high priority, simple edge links, and even an extension of the configuration (.PGM) files!

Larry Dickson