Transputer-> Forgotten Futures
pete
As things have started to move on the Transputer front. I thought that a
couple of threads
should be joined, to make a more coherant discussion.
From the e-mails from Paul Walker he is dashing around and hopefully
will bring back
good news for us all. With the next WoTug meeting in Canterbury shortly
(I must profess
my complete ignorance of it until Paul Walker informed me of it), a
collect of the ideas
could be useful.
If a new transputer is to be produced what would be the items to be
included on the silicon
a basic core as per the 32bit T800
an FPU as per the 32bit T800
the question of the MMU would need to be resolved
microcode compatability with the 32 core
more on board ram
a faster core and bus interface
The software to use the 3L C compiler
a design of the os based on a nano kernel orientated to the transputer
the software to be cheap, fsf, or gpl for greater access to the public
( I feel that the price was one of the major problems which caused the
access to the general public and developer's)
The design of the silicon to use the Handel-C route so that the silicon
can be proofed prior the implementation ( let's use the tools that have
arrived
since the first build of the transputer).
Have I missed anything out?
If so added it please
pete
Andy Rabagliati
According to pete <pe...@feeney.co.uk>:
> If a new transputer is to be produced what would be the items to be
> included on the silicon a basic core as per the 32bit T800 an FPU as
> per the 32bit T800 the question of the MMU would need to be resolved
I cannot see an MMU happening, for all the same reasons it never
happened before. Trying to make it a mainstream CPU will fail.
DS links would be great. However, they go hand in hand with the virtual
channel routing of the T9000, which would need to be added.
The transputer was :-
1 - a parallel processor
2 - an embedded processor
3 - a link processor.
What do we want for the next generation ? Priorities should be set.
We want links.
We want parallelism.
I think we can drop the embedded label if necessary.
> Have I missed anything out?
The transputer micro-kernel (scheduler, PAR, ALT) is patented.
Is SGS-Thomson willing to release it ?
Cheers, Andy!
Jan Vorbrueggen
an...@rmi.net (Andy Rabagliati) writes:
> The transputer micro-kernel (scheduler, PAR, ALT) is patented.
Really? The patent system must be even more broken then I ever imagined. The
actual _implementation_ of the ALT is the only thing I can see being patented
(and it's one of the few things that had a conceptual bug 8-))...
Jan
Alec Cawley
In article <6bcs4c$qi0$1...@news1.rmi.net>, Andy Rabagliati <an...@rmi.net>
writes
>The transputer was :-
>
>1 - a parallel processor
>2 - an embedded processor
>3 - a link processor.
>
>What do we want for the next generation ? Priorities should be set.
>
> We want links.
> We want parallelism.
> I think we can drop the embedded label if necessary.
The transputer "grew" the embedded label - it wasn't originally designed
with it, but designed such that it had minimal/no support chips needed,
because it was to be replicated in large quantities. I want to use any
transputer for embedded applications. But my use of "embedded" is
roughly the same - very low glue logic i.e. a direct dram interface
*not* a standard bus. Links and parallelism are both central to the
tranputer concept. In the short term, I want a rear-drop-in tranputer
replacement i.e. OS links, point to point from the chip. In the medium
term, the merits of virtual links are so overwhelming that I think we
would want them.
--
Alec Cawley
Newbury
Berks, UK
pete
somebody please explain to the ignorant one
virtual channels how are these different from the software channels?
DS links --- sorry don't understand are these the hardware channels?
the reason for making this processor mainstream is so that it doesn't go
the same way again.
the uses could be manyfold from plugin accelerator engines through
database servers to web servers.
Andy Rabagliati
According to pete <pe...@feeney.co.uk>:
> virtual channels how are these different from the software channels?
Virtual channels are basically hardware-multiplexed software channels
over a single physical link.
It is arranged, via buffering and packetizing, that these software
channels do not block each other. They can (and are) modelled on
T4/8 transputers in software.
> DS links --- sorry don't understand are these the hardware channels?
This is the Data/Strobe link standard of the T9000. A modern-day
manchester encoding using two signal lines in each direction,
they are self-synchronising, and can be AC coupled.
The Old Style (OS) links are RS232 with an extra bit or two
thrown in for Acknowledges. They require over-sampled DC-coupled
connections.
DS links also synchronise by the packet, not by the byte, making
the performance less sensitive to latency delays.
Last, but not least, DS ran up to 150Mbit/sec, where OS (5x oversampled)
could only manage 20Mbit.
Cheers, Andy!
pete
light dawns!!
they are both a must then from my own experience of programming the T800's
that I have.
now the next point I saw raised
pin for pin compatability but with which unit?
as which of the transputers are the most commonly used?
pete
Alec Cawley
In article <34DAD196...@feeney.co.uk>, pete <pe...@feeney.co.uk>
writes
Pin compatability would be nice, and speed acceptance, but is not
essential. Of course, if you have modelled properly, a Mk1 pin-
compatible to prove your point and "open" the market could be followed
by a Mk2 with an improved pinout if such were valuable.
I would have thought that the T425/T805 pinout was by far the most
widely used; or was the 801 with non-multplexed bus more widely used
than I thought? Someeople might want the T400 plastic package, not used
on the 425 for heat reasons, I think. How expensive is it to support
both this and PGA (which we use)?
pete
I think the idea of a pin compatibility as first generation then a new package
format for Mk would be a good way to go as with the increase in speed
a non multiplexed bus would be the better option.
supporting different package formats is a cost consideration I believe the
plastic packages are cheaper but not so good with heat
pete
David Arnold
pete <pe...@feeney.co.uk> writes:
> Alec Cawley wrote:
>
> > Pin compatability would be nice, and speed acceptance, but is not
> > essential.
how useful would TRAM compatibility be? it would be easier to get the
new package(s) onto a TRAM ...
-- David Arnold ,=================================================
=================' +617 33654310 (voice)
CRC for Distributed Systems Technology +617 33654311 (fax)
University of Queensland dav...@pobox.com (email)
Australia <http://www.pobox.com/~davida> (web)
In theory, there is no difference between theory and practice; in
practice, however, there is no similarity - Dave Butenhof.
Alec Cawley
In article <o41zxc1...@ember.dstc.edu.au>, David Arnold
<arn...@ember.dstc.edu.au> writes
>pete <pe...@feeney.co.uk> writes:
>> Alec Cawley wrote:
>>
>> > Pin compatability would be nice, and speed acceptance, but is not
>> > essential.
>
>
>how useful would TRAM compatibility be? it would be easier to get the
>new package(s) onto a TRAM ...
No use to me, because we have to take the bus to the perpherals we are
controlling, but others may be interested. I can see that Tram
compatability would be much easier to acheive.
Iann Barron
In article <qY6DzIAJ...@cawley.demon.co.uk>, Alec Cawley
<al...@cawley.demon.co.uk> writes
>The transputer "grew" the embedded label - it wasn't originally designed
>with it, but designed such that it had minimal/no support chips needed,
>because it was to be replicated in large quantities.
No, the transputer was specifically designed as an embedded chip, as
well as a parallel processing chip. I thought that the market for
parallel processing would take a considerable time to develop (but not
as long as this), and it was necessary to have an intermediate market to
support the transputer. An embedded chip has almost the same
requirements as a parallel processing chip - the difference is just
being connected to devices other than transputers.
Of course, there were lots of other strategic considerations in the
design of the transputer.
--
** Iann Barron **
* Barrow Court * Barrow Gurney * Somerset * (UK) BS19 3RW *
(44) 1275 46 3748 (voice) * (44) 1275 46 3368 (fax)
Alec Cawley
In article <X0xr9WAp...@mynchen.demon.co.uk>, Iann Barron
<ia...@mynchen.demon.co.uk> writes
>In article <qY6DzIAJ...@cawley.demon.co.uk>, Alec Cawley
><al...@cawley.demon.co.uk> writes
>>The transputer "grew" the embedded label - it wasn't originally designed
>>with it, but designed such that it had minimal/no support chips needed,
>>because it was to be replicated in large quantities.
>
>No, the transputer was specifically designed as an embedded chip, as
>well as a parallel processing chip. I thought that the market for
>parallel processing would take a considerable time to develop (but not
>as long as this), and it was necessary to have an intermediate market to
>support the transputer. An embedded chip has almost the same
>requirements as a parallel processing chip - the difference is just
>being connected to devices other than transputers.
Straight from the horse's mouth - I can hardly contradict that. In which
case, why was support for the embedded user so rotten for so long? It
took me approximately 10 years to get one designed in, despite wanting
to do so from before the time the first devices appeared.
Iain A F Fleming
On Sat, 14 Feb 1998 10:52:25 +0000,
Iann Barron <ia...@mynchen.demon.co.uk>,
> No, the transputer was specifically designed as an embedded chip,
> An embedded chip has almost the same requirements as a parallel
> processing chip
And, indeed, since the transputer, other embedded processors have had
links of sorts - the Ti TMS320C4x (and the C8 which has several
processors on one chip), and the Analog Devices SHARC.
However, all of them suffer from link technologies that are
over-complicated. And in the case of the SHARC, also a downright
hostile instruction set...
--
Iain A F Fleming http://www.threel.co.uk/
3L Ltd 86/92 Causewayside Edinburgh Scotland
David Boreham
Iann Barron wrote:
> No, the transputer was specifically designed as an embedded chip, as
> well as a parallel processing chip.
I have a very dim memory of an article in perhaps
Personal Computer World c. 1983. Might
have been written by Dick Pountain. Anyway,
this was the first time I'd heard about the transputer
and it was all about building telecoms systems.
Nothing about supercomputers.
It would be interesting if someone still had a
copy of this article and could get permission
to post it here.