jhhur@sorak.kaist.ac.kr (jhhur) (05/12/88)
Per my request dated 18 March, I got three replies. Two pointed the Trillium of Cornell and one addressed the general issues of Transputer's capability. [Sorry for late summary.] Transputer inherently has no MMU capability, but there are two ways to overcome the limitation: one in hardware (I have no more information on the company that developed the MMU circuitary for the T4's) and one in softare (You may refer to the Dave Poplawski's paper in 1987 Parallel Processing Conference proceedings). Those who are interested in the Transputer OS will find Trillium interesting. Though there are only the reference manual available from Greg Burns, it seems to be the first step for the Transputer OS. Anyway, I enclose the replies. I don't enclose my questions since it is included in the first reply. ================== Message inbox:71 - Read >From: Colin Plumb <ccplumb@math.waterloo.edu> To: <jhhur@sorak.kaist.ac.kr> In-Reply-To: inbox:43 Subject: Re: Memory management capability of Transputer >From ccplumb@math.waterloo.edu Mon Mar 21 10:11:18 1988 >Newsgroups: comp.sys.transputer >Summary: >Confusion: U. of Waterloo, Ontario In comp.sys.transputer you wrote: >Our group are now evaluating Transputer and 80386 for our project of building >a multiprocessor system for our project. There, one question >arised and I found no answer from the Transputer architecture reference manual >(RM) and the compiler writer's guide (CWG). >Is there anybody out there who can answer to our questions? I'll see what I can do. I've worked on OS's for custom boards. >Our requirements: > > Basic unit of computation in our system is object which is > comprised of an address space and a set of execution thread. > We need the object to be dynnmically loadable and the execution > threads (concurrent processes in T4/T8) to be created over those > objects. In that regard, we appreciate the capability of Transputer > to create a process very cheaply. But w.r.t. the program image > loading, we want to that in run time, not just in reset or analyse > time as is specified in RM. This is certainly doable, but the Transputer is absolutely *lousy* for maintaining separate address spaces. There is no user/supervisor distinction and, in fact, no way to detect a context switch except by the pattern of memory accesses (hard). It also doesn't support memory access faults. On receiving an interrupt, the current instruction completes. >Our interpretation of Tranputer: > > There are two way to load program images on Transputer from our > understanding of the RM and CWG: > (1) Upon reset or analyse, the transputer is ready to accept the > program image over any links. Based on the first byte, it loads > the program on MemStart and jumps to it. This program must be < 256 bytes, so it's only a bootstrap loader. It must then load the real program. > (2) Upon analyse, one can peek/poke the memory of Transputer. Yes. >Questions: > > (1) Should the program image be loaded a priori for a process on > the image to be created? > (2) Related to (1) above, is there any way to load a part of the > program image upon demand? For it to be possible, there should be > a mechamism to raise a trap upon invalid code address (a ka page > fault) so that any pre-defined program be invoked to load the > wanted part of the image. RM or CWG mentions nothing about that. Well, there is the MMU problem... you could go the software route (a la Mac - go through a jump table that initially points to reload code) but hardware is expensive. And hard. It might be possible to put protection on the real address space, and figure out what blank entries aer supposed to be full of, based on a load map. > (3) Or, is there a room for a MMU circuitary to be attached to the > external memory interface of Transputer? Put simply, no. > (4) Is there any way to load the program image while the transputer > is running? We may imaging the following scenario like we allocate > a persistent process be running over each channel, define a protocol > for it to recognize a program image loading phase, let it poke the > remaining message to the specified location in the message, and > create a process over the image. Is it the only way we can > imagine? Well, you could elaborate it considerably. Like put a memory manager on each processor, so the load addresses could be distinct. Essentially, do anything a reasoable processor could do without MMU. But this is the way bootstrap loaders work, and they work fine. -- -Colin (watmath!ccplumb) Zippy says: I think I am an overnight sensation right now!! ================== Message inbox:44 - Read >From: Greg Burns <gdburns@tcgould.tn.cornell.edu> To: <jhhur@sorak.kaist.ac.kr> Subject: Re: Memory management capability of Transputer >From root Sat Mar 19 17:30:47 1988 Are you the guys who contacted me about Trillium? Many of your questions are answered by a transputer operating system called Trillium which was recently developed here at Cornell. We can load code images dynamically, on the fly and as many as we want. We can spawn programs to other nodes, kill them off, find out what they are doing, pass messages between arbitrary processes on arbitrary nodes, with or without buffers, and several other goodies as well. A real MMU for the current transputer chips does not seem possible. A partial solution is being offered by Topologix of Denver, CO. As for trapping and bringing in subsequent code pages, David Poplawski of Michigan Tech. U. has made a proposal to do just that on a transputer network (and without an MMU, though with translator help). You might want to contact him about his ideas. --Greg ================== Message inbox:64 - Read >From: braner <braner@tcgould.tn.cornell.edu> To: <jhhur@sorak.kaist.ac.kr> In-Reply-To: inbox:43 Subject: Re: Memory management capability of Transputer >From root Sun Mar 20 10:12:23 1988 >Newsgroups: comp.sys.transputer >Organization: Cornell Theory Center, Cornell University, Ithaca NY Hi! The Inmos documents don't describe such things since they like Occam, where everything is done at compile time. Here at Cornell we have developed Trillium, an operating system for a network of parallel processors, including (especially) a network of transputers plus a UNIX host. Whether you use Trillium or some other kernel software, you can do whatever you want with dynamic loading of objects. You need to have the kernel blocked on waiting for a message to that effect, and preferably in high priority. In Trillium a user can load programs into a transputer while others are already running. Any part of RAM can easily be loaded with code and queued as a process. There is, however, no way to trap access to the wrong memory addresses by a process on the transputer without external hardware. I have heard of a company that has already developed an external MMU for the transputer that does not slow down memory access (on a 20MHz T800). Sounds great. It is a custom chip for a proprietory board, though, probably not available for your project... - Moshe Braner