RE: Transputer

From: Sympa,pkg125 [mailto:sympa@xxxxxxxxxx] On Behalf Of Larry Dickson
Sent: 20 June 2013 18:44
To: Ruth Ivimey-Cook
Cc: Barry Cook (4Links); occam-com@xxxxxxxxxx; 'wotug-com@xxxxxxxxxx'
Subject: Re: Transputer

On Jun 20, 2013, at 10:08 AM, Ruth Ivimey-Cook <ruth@xxxxxxxxxx> wrote:

Larry Dickson wrote:

I certainly agree with this idea. Prof. May suggested some space be given to memory (cache-like, I suppose, just as on the original Transputer). I suggest in addition a lot more links and event lines, plus analog/digital data lines - say 16 links, 16 events, 64 A or D. (Or am I thinking too small?) Each could have a dedicated Transputer on the "edge" in the spirit of Prof. May's preferred design (in our big priorities discussion last Sep-Oct). Even if only 2000 of the Transputers are left, there should be plenty of edge (45 x 45 = 2025 and that's 176 on the edge if a square array).

If it were me I'd need an generalised and fast interconnect that was at least as good as the old Tp virtual router, then make I/O connections (A-D, etc) dedicated entities in preference to having "special" CPUs... that always causes problems in implementation.

We seem to be talking past each other here. The virtual router (if it's the crossbar switch I'm thinking of) connected multiple Transputers (separate chips) where I believe Prof. May is talking about thousands of Transputers on a single die. You could add a crossbar switch (or a bunch of them) within the die but the question would still remain which of the Transputers each crossbar was connected to. Basically, programming the crossbars would replace programming the "edge" Transputers, and that looks even more complex to me, two species to deal with, and a lot of virtualization, which could be either a plus or a minus. As I remember, non-default settings of the crossbars were little used on the historic Transputer boards.

I'd also like to experiment (at least) with remote memory - each CPU has local memory which is mapped as virtual memory for every other CPU - and when setting this up a CPU can declare how much its willing to donate and what access time it has, so making disk based VM integrated into the scheme as well.

The problem with this is you'd need to extend the transputer (or early ARM) architecures to support VM, let alone the need for the supporting hardware.

I don't see why. There could be a general address space (probably 2D) and each Transputer would have its home region in that space, closely resembling its actual location on the die. Then just allow 2D <-> 1D memory aliasing primitives (subarray - stride) and everything stays natural instead of the horrible distortions introduced by VM.

Larry

[[I think at least some of these ideas came from Barry & Roger's ParaPC]]

Regards
Ruth

--

Software Manager & Engineer

Tel: 01223 414180

Blog: http://www.ivimey.org/blog

LinkedIn: http://uk.linkedin.com/in/ruthivimeycook/

Larry says : “I don't see why. There could be a general address space (probably 2D) and each Transputer would have its home region in that space, closely resembling its actual location on the die. Then just allow 2D <-> 1D memory aliasing primitives (subarray - stride)”

This is somewhat similar to the memory on the Adapteva Epiphany : each processor can address the whole memory set using a 32 bit address, it is just faster to access the local memory using a part of the address range.