Thread View: comp.sys.transputer
2 messages
2 total messages
Started by Paul Chapman
Sat, 22 Jul 1989 11:03
Re: Transputer vs. i860
Author: Paul Chapman
Date: Sat, 22 Jul 1989 11:03
Date: Sat, 22 Jul 1989 11:03
40 lines
2591 bytes
2591 bytes
In a recent message Peter Siemon writes :- >> So - if INMOS looses. I do not care. The idea of parallel processing has >> not been invented by them. And it might be perfected by someone else! If you feel so negative about Transputers why are you using them? Or are you just waiting for something better to come along? BUT if you are doing something worthwhile shouldn't you be concerned that your supplier may be in danger of beeing squeezed out of business and everything you have done becoming obsolete. No doubt anything you have done can be transfered to another device, but I for one have invested a great deal of time in Occam and have no desire to rewrite it all. >> What Craig Davidson (says) is perfectly o.k. But his conclusion is wrong. >> Obviously INTEL is the better company, has the better product, the better >> marketing, the better service and the better support. NO obviously about it. I think Craig's remarks are very much to the point. The British have a long tradition of developing good ideas and not being able to capitalise on them and I see no reason for the Transputer to be any different. The brutal truth is that Our Beloved (?!) Prime Minister's attempts to Americanise our economy by placing it at the mercy of market forces has not worked because there is not, and has not been for far too long, the degree of investment (both in terms of capital and management expertise) that is required in our industry -- the abysmal under-funding of Inmos by Thorn-EMI is just one more testimony to that. I have heard more than one person express the view that Inmos survives despite, rather than because, of the way it is run. On top of all this, US firms have the advantage of a huge home market on which to develop their products. The question is whether 1992 will come in time to save the Transputer!! Unfortunately there is not much we can do on this net to change Inmos company policy. However, it would be interesting to hear from those in The Company who get this stuff, to see what they think -- or is this to contentious to handle without fear of unemployment !?! Paul Chapman. (Dept. Computer Science, Bristol University, U.K.)
Problem with Occam, HELP !
Author: Phil M Sleat
Date: Thu, 27 Jul 1989 08:57
Date: Thu, 27 Jul 1989 08:57
113 lines
3866 bytes
3866 bytes
I appear to have a problem running an application on a network of
transputers. I would be grateful if anyone can point out what is
probably a glaringly obvious mistake in my Occam code, or perhaps
suggest an alternative solution.
I shall illustrate my problem using the following example. Suppose
I have two transputers connected and wish to have two communicating
processes runnning on them. Instead of directly linking the two
processes together via a logical channel and then assigning this
logical channel to a physical link, I have the two processes talk to
multiplexor/de-multiplexor processes which handle the communication
across the physical link.
For example on processor 1 the following might be running:
PROC mux1(CHAN OF prots01 prots01IN, prots01OUT, CHAN OF INT p1c0,
CHAN OF INT signal)
INT sig:
INT v0:
SEQ
sig := 0
WHILE (sig <> 1)
ALT
prots01IN ? CASE
p0p1t0 ; v0
p1c0 ! v0
p1c0 ? v0
prots01OUT ! p0p1t0 ; v0
signal ? sig
SKIP
:
PROC receive(CHAN OF INT a)
INT res:
SEQ
a ? res
--
-- process data
a ! res
:
Both of these processes would be called from a master process for
processor 1 which has
CHAN OF INT p1c0:
CHAN OF INT signal:
PAR
mux1(prots01OUT,prots01IN,p1c0,signal)
SEQ
receive(p1c0)
signal ! 1
:
where prots01OUT and prots01IN are assigned to physical links connected
to processor 0.
Running on processor 0 we have a similar set of code:
PROC mux0(CHAN OF prots01 prots01OUT, prots01IN, CHAN OF INT p0c0,
CHAN OF INT signal)
INT v0;
INT sig:
SEQ
sig := 0
WHILE (sig <> 1)
ALT
prots01IN ? CASE
p0p1t0 ; v0
p0c0 ! v0
p0c0 ? v0
prots01OUT ! p0p1t0 ; v0
signal ? sig
SKIP
:
PROC display(a)
INT res:
SEQ
a ! 2
a ? res
--
-- consume results
:
The processes on processor 0 are called in a similar manner to that on
processor 1. The protocol prots01 is a simple protocol of 1 tag p0p1t0
but the intension is to extend it so that more than one process may
communicate through the muliplexor.
I've checked the assignment of channels to links and they are okay.
Indeed in the above simple code when I replace all the processes on
processor 1 by simple sequential code to accept a number from
processor 0 and return a reply, the multiplexor on processor 0 works
okay. The same is for the multiplexor on processor 1 when I replace
mux0 by sequential code. The multiplexors appear to function in
isolation (!) but not together.
Could it be a problem with the ALT in the multiplexor ? I've tried
a PRI ALT with physical link communication of higher priority bu that
doesn't seem to work any better.
If anyone has any ideas as to why the above doesn't work I'd be very
grateful. I hope I've included enough information to detail my
problem.
Many thanks in advance for any replies.
Phil M Sleat
phils@uk.ac.city.cs
--------------------------------------------------------------------------
City University, Computer Science Dept
Northampton Sq
London
Thread Navigation
This is a paginated view of messages in the thread with full content displayed inline.
Messages are displayed in chronological order, with the original post highlighted in green.
Use pagination controls to navigate through all messages in large threads.
Back to All Threads