Re: Question on T9000

[Roger Shepherd <rog@xxxxxxxx>]

Larry 

Much to my amazement I couldn’t find a copy of the official documentation on my shelves….. But my google is my friend and I now have an electronic copy (although not OCR’d). But the documentation looks pretty good to me. 

So, to some of your points:

“Logical” v. “Virtual”

Both are non-physical; virtual addresses are logical addresses, but not necessarily vice versa. 

Logical address must be translated into physical addressss. Commonly this is done using page tables, where the address space is split into pages of a particular size and a table of translations is maintained, one entry for each page which has to be translated (there are many variations but this is the simplest version for the purpose of explanation). In the T9000, addresses are translated, but not with a page-based mechanism.

The key property of virtual addresses is that, it should be possible to run with only some of the required physical memory being present. This is achieved by the processor “faulting” when it attempts to access a logical address for which the corresponding physical location is not present or allocated, and being able to recover from the fault once the physical memory were made available

On 23 Dec 2016, at 18:13, Larry Dickson <tjoccam@xxxxxxxxxxx> wrote:

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