HDTenEightyP/NetNews huggingface dataset:
From: heller@lisboa (Helmut Heller)
Subject: Re: How many Transputers are enough?
Reply-To: heller@lisboa.ks.uiuc.edu
Organization: University of Illinois at Urbana
Date: Thu, 13 Aug 1992 16:53:47 GMT

In article <1992Aug13.102814.12544@aiware.in-berlin.de> scm@aiware.in-berlin.de  
(Harald Schmidt) writes:
> Hallihallo,
> 
> does anybody know the max. number of transputers I can connect,
> and the resulting MIPS/MFLOPS.
> What is the best price/power-ratio?
> 
> Thanks for any infomation,
> 
> 	Harald
> -- 
There is no maximal number, only your financial funds will limit the size of your  
machine :-).
The theoretical MIPS/MFLOPS performance increases linear with the number of your  
Transputers, but the actual MIPS/MFLOPS value will be less than that, strongly  
depending on your application.
Therefore, with 1 Transputer you will get the best price/power-ratio, but this is  
probably not what you want :-)

64 or 128 T800 make quite a nice machine. If you want to test your application  
first, before you spend DM 100000s, I could offer you a guest login on our  
Transputer guest account tguest. There you could experiment with up to 5 T800 for  
free. Send me e-mail if you are interested.

Viele Gruesse nach Deutschland,
--
Servus, Helmut  (W9/DH0MAD) ______________NeXT-mail preferred________________
heller@lisboa.ks.uiuc.edu   "Knowledge must be gathered and cannot be given" 
FAX:   (217)244-8371                      ZEN, one of BLAKES7                
Phone: (217)244-6914        -------------------------------------------------
Helmut Heller, University of Illinois at Urbana-Champaign, Beckman Institute
Theoretical Biophysics Group, Room 3143, MC 251
From: SN=Mitchell_Reifel@SU=Reifel (Mitchell Reifel)
Newsgroups: comp.sys.transputer
Subject: TEXAS INSTRUMENTS' Electronic Mail message # 198017
Date: 18 Aug 92 17:50:00 GMT
Distribution: world
Organization: The Internet

-----------------------------
Application message id:  TI.msg.198017
Grade of Delivery:  Normal

-----------------------------
 
In a previous article Stephen Doyle of Inmos writes:
 
> Your statement on Texas is inaccurate. It is a credit to the transputer
> (and perhaps a reflection on Texas' offerings) that there have not
> been design-in losses to Texas.
 
I have to disagree.  The number of customers who have switched from the T9000
to the C40 is quite considerable.  The number of units to date numbers in the
tens of thousands with revenue worth millions of dollars.
 
Also, the number of "third party" vendors who have included C40 support with
their Transputer support (3L, Perihelion, etc.) numbers over two dozen. Since
these companies position their products where the revenue is, it is a good
market indicator for the C40.
 
> There is still only one real transputer family and randomly sticking links on
> a processor does not make it a contender. An interpretation of the situation
> could be that even a (previously) absent T9000 is considered better than a
> real C30/C40.
 
Some people out there would agree with your opinion.  Others don't.  The market
will eventually decide.  I think the outcome will be that both products will
find their niche in the market.  Users will choose different options for
different reasons.  In some cases the two will be competing for the same
socket.  In others, the two processors will complement each other (there are
already a number of designs employing both). The main outcome, however, is that
the Transputer no longer has a monopoly in this market.
 
Regards,
Mitch Reifel
TMS320C40 Program Manager
Texas Instruments, Houston, Texas
5140840@mcimail.com
From: sjb@THEORY.TC.CORNELL.EDU (Stephen J. Bradshaw)
Newsgroups: comp.sys.transputer
Subject: C40 info (part 2: software)
Date: 19 Aug 92 16:28:41 GMT
Distribution: world
Organization: The Internet


In my previous message, I negleted to say anything about software for
systems involving both transputers and C40 processors. So here goes..

3L recently developed a C40 version of their well known and established
parallel compiler for transputer systems. The C40 version provides source
code compatibility for software previously developed under 3L C for 
transputers.

What is particularly interesting about the 3L product (portfolio) is
that it provides support for heterogeneous hardware systems which
consist of transputers AND C40 processors. In essense, you end up
developing C code in the usual manner but then indicate which
processors and type of processors get which tasks. The appropriate
compiler is then used to compile down for respective processors.

As a result, software programmers could utilize a mixed network of C40
processors and transputers as a homogeneous system. 3L have also dealt
with the various low level data representation issues so that you
don't even have to worry about packing and unpacking data or anything
else like that.

Althoug biased (we distribute 3L software with our C40 and transputer
systems), we have been very impressed by this product and its ability to
retain the "look and feel" of a transputer system on other hardware.
There are obvious technical issues that make C40 hardware systems
different from transputer hardware systems, but their similarities are
made very clear when using 3L, or C40-Helios for that matter.

Regards,


Steve Bradshaw                 "For, so long as a hundred of us remain alive, 
                                we never will in any degree be subject to the 
Traquair Data Systems           dominion of the English. Since it is not for
Judd Falls Plaza, Suite 80      glory, riches or honours we fight, but for 
Ithaca, NY 14850                liberty alone, which no good man loses but 
                                with his life." 

Phone: (607) 272 4417           Robert de Bruce, King of Scotland:
Fax:   (607) 272 6211                      The Declaration Of Arbroath 1320
From: cliff@netcom.com (Cliff Rodriquiez)
Newsgroups: comp.sys.transputer
Subject: IMPORTANT questions. please read
Date: 21 Aug 92 16:13:37 GMT
Article-I.D.: netcom.zv_nwff.cliff
Organization: Netcom - Online Communication Services  (408 241-9760 guest)

I am doing a VR game.  My original hardware choice
was to use transputers for the graphics pipeline.

I don't have ANY experience with transputers.  I've
been doing as much reading on parallel graphics and
transputer archs as possible and will probably hire
someone to do part of the work.

If you have experience with transputers and graphics,
could you please answer one or more of these questions?
I'm funding this project myself, the more info I have
the better chance of the investment being worth while.
thanks in advance.....cliff

note: i am looking at an intel 486 system and adding
      cards on for co-processing.

1.  on a price per performance basis, is the i860 better
    than the transputer?  i see the very low mips of 
    a T800 and wonder how many i would need in parallel
    to make up one i860.

2.  transputers seem to be a lot more expensive than
    i originally thought.  if i want to put 3-4 on
    my machine and give them each a couple of meg
    i am talking about serious bucks (pricing from
    my local inmos dist in sunnyvale ca).  has anyone
    seen good pricing?  is there an alternative to
    using inmos transputers?  what are some prices 
    you have seen for: transputer boards for pc's,
    trams, memory for trams.  

3.  i am currently developing my own 3d routines that
    will be ported over to the transputer env.  the i860
    has quite a lot of 3d hardware/software support.  has
    anyone see graphics libraries and/or specialize graphics
    hardware for the transputer?  my catalog only shows a 
    simple (vga like) display chip.  i would like something
    a little more performance oriented tward 2d and 3d 
    graphics.

4.  last question:

    if i am going to all the trouble of making a graphics
    pipeline with transputers that are around 1-2 mips,
    am i kidding myself when compared to:

    specialized 3d hardware designed for high performance
    polygon throughput, coupled with a risc based motherboard
    giving me 15 mips.  

  thanks again?  i can accept the answers/comments/questions on
  the net or to cliff@netcom.com .  if you want me to post the
  results i will. thanks again.

  ps.  i may make some of the results of my project public domain.
-- 

-- 
Cliff Rodriguez 
C&R Software Solutions
voice 408-252-1429
fax 408-252-5909
cliff@netcom.com or apple!netcom!cliff
P.O Box 95015-0658 Cupertino Ca. 95015 USA
From: sjb@THEORY.TC.CORNELL.EDU (Stephen J. Bradshaw)
Newsgroups: comp.sys.transputer
Subject: Mixed C40/transputer networks
Date: 22 Aug 92 15:56:44 GMT
Distribution: world
Organization: The Internet


> Never having used a C40 (this being comp.sys.transputer) the
> following questions come to mind.

I would have thought that the C40 is sufficiently similar to the
transputer, at least in concept, that comp.sys.transputer is a suitable
place for such discussions. After all, it gives people such as Mr.
Doyle, of the Software Marketing Group at Inmos, the opportunity to
tell us how much better the real thing will be :^)

> 1. Its a newer chip then a T8 and clearly faster, but it an actual
> multiprocessing system do you get more bang per buck?
> 

(1)	A 50 MFLOP CPU.

(2)	Six bi-directional 20 MBytes/s Communication Ports (Links)

(3)	Six channel DMA co-processor enabling concurrent operation of
	Communication Ports and CPU

(4)	Two 100 MBytes/s Memory Ports

(5)     On-chip analysis module with JTAG (IEEE1149.1) interface.
	Monitors activities of processor, enables control of
	breakpoints, and privides read/write access to full memory map.

(6)	TIM-40 standard, the TRAM standard of the C40 market.

(7)	Source compatibility offered by Helios and 3L

> 2. Is the architecture up to the job? Context switch time is just as
> important as comunications speed. To get the much sort after linear
> increase in performace
> 
>         Performance     |   /
>                         |  /
>                         | /
>                         |/
>                         |--------
>                                 No of processors
> each processor must be able to fill up all its available time. To do
> this it must be able to quickly do something else while it waits for
> other processors i.e. Context switch

The is obviously dependent on the hardware but ultimately a function of
the software system being used, as the C40 does not support multi-tasking
in hardware as does the tranpsuter. Spectron Microsystems, for example,
quote a "task" switching time for SPOX of 18 processor cycles. This is
the time to complete the last instruction of one task to being ready to
execute the first instruction of the next task.

Your comments about keeping the CPU busy should of course be inscribed
on every transputer users brain (mine included). Keeping the CPU busy
is also possible on the C40 since the Comm Ports can run autonomously
with the CPU. The same rules apply but the numbers are different.


Steve Bradshaw             	Radioactive cats have 18 half-lives !    

Traquair Data Systems           
Judd Falls Plaza, Suite 80      Phone:	(607) 272 4417
Ithaca, NY 14850                Fax:	(607) 272 6211
From: mkc@SABAL.CIS.UFL.EDU ("Madhan Chidambaram")
Newsgroups: comp.sys.transputer
Subject: please remove me from the mailing list.
Date: 13 Aug 92 16:11:57 GMT
Organization: The Internet


Please remove me from the mailing list.

thanks,

madhan.
From: henshaw@emperor.gatech.edu (Andy Henshaw)
Newsgroups: comp.sys.transputer
Subject: Re: T9000 status
Date: 17 Aug 92 17:49:29 GMT
Organization: CERL-EE, Georgia Institute of Technology

Steve Doyle writes:

>(and perhaps a reflection on Texas' offerings) that there have not
>been design-in losses to Texas. 

 I think that I am not atypical in thinking that this shortening
of Texas Instruments' name sounds very weird to people here in the
States.  Generally, we refer to them as TI.  Obviously, Texas brings
to mind the state.  Not an insightful message, I know, but traffic is
low in this group anyway.

Andy Henshaw
From: ian@buckingham.ac.uk (Ian East)
Newsgroups: comp.sys.transputer
Subject: occam
Date: 14 Aug 92 08:44:19 GMT
Distribution: world
Organization: The Internet



If there's a wall around I'll bang my head against it. With luck enough others
might bang this one. Yer never know it might fall down.

occam is not dead. It is in widespread use throughout the transputer development
community by those who are willing to try it out and listen to its arguments.

Why is occam so good? The potted version: security, explicit concurrency,
readability and run-time modularity via processes. (It is easy to think and
reason about a system as a network of processes at run-time. These are easily
expressed and read in occam.) Security is not easy to achieve in a concurrent
system. occam makes it a hell of a lot easier. Besides, is it so unreasonable
to use a parallel programming language to do parallel programming. I have seen
code written in C for transputers which has been recoded in occam. I know which
I would rather read and trust!

My message is simply this. TRY IT! It is the easiest language I've ever learned
and by far and away the most rewarding to use.

occam 3 will provide source-code modularity too, which just about picks up all
the requirements of a modern programming language. All we need now is compilers
for a range of targets (especially Macs, Suns as used in teaching establishments
so as to broaden the expertise base). These appear at last to be on their way
now that Inmos have released source for their compiler,

Ian East
ian%buck@uk.ac.ukNet
University of Buckingham
From: mapsajw@gdr.bath.ac.uk (S A J Winder)
Newsgroups: comp.sys.transputer
Subject: Wanted: Cross-Assembler
Date: 12 Aug 92 18:00:29 GMT
Organization: Bath University Computing Group

Wanted: PC based cross-assembler
--------------------------------

Can anyone point me to an ftp-able cross-assembler to generate T400/T800
object code on the PC? I need the assembler to be stand alone software,
unlike the TDS.

Thanks,

Simon

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 Simon A.J. Winder             Computer Vision Research
 sajw@uk.ac.bath.maths    University of Bath Computing Group
 Tel: +44 (0)225 826183   /\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
From: duha@rekpmx.biomed.mcgill.ca (Jan A. Duha)
Newsgroups: comp.sys.transputer
Subject: Trip
Date: 19 Aug 92 14:54:23 GMT
Organization: Neuromuscular Control Lab

Greetings!

  This Friday (Aug. 21), I'm leaving on a two-week vacation to Europe;
I'll be visiting France, the south-west part of Germany, and Switzerland.  

  In addition to touring the countryside, I was hoping to explore some
of the local transputer research.  Is there anyone working in 
those countries who wouldn't mind a brief visit from me on such short 
notice?

  Thanks,

  Jan Duha
  duha@rekpmx.biomed.mcgill.ca
  duha@ee470.ee.mcgill.ca
From: STALKER@CAPSRV.JHUAPL.EDU
Newsgroups: comp.sys.transputer
Subject: T9000 Delay?
Date: 12 Aug 92 20:15:00 GMT
Distribution: world
Organization: The Internet

Dear Netters:

A few days ago, James K. Prater commented on an unexpected delay
for the release of the INMOS T9000 chip.  Does anybody has any
additional comments or learned about this delay from a different
source?  We are interested to know the fate of the T9000 if it
ever hits the market.  I also would like to know why this forum
of information/disputes/commentaries has been kept so quietly
lately.  Has the general interest on the transputer dropped so
dramatically that nobody cares to put any lines here?  So we use
this forum to comment on other parallel architectures or related
research?  Think about it...

Mario Stalker
SYSCON CORPORATION
stalker@capsrv.jhuapl.edu
From: sjb@THEORY.TC.CORNELL.EDU (Stephen J. Bradshaw)
Newsgroups: comp.sys.transputer
Subject: C40 Info
Date: 18 Aug 92 23:21:31 GMT
Distribution: world
Organization: The Internet

> Is there a list of current vendors who are offering support (hardware
> and software) for the C40? I've been trying to follow what's available
> for it since it was first announced, but haven't seen that much
> advertising done.

Yes there is. Actually it is a TI publication which you can get by
calling (800) 336 5236 or their DSP hotline (713) 274 2320. I'm sorry I
dont have access to the appropriate telephone numbers outside the US.
At worst, just call your local TI office and ask them to arrange for a
copy to be sent to you.


	TMS320 Third Party Support Reference Guide
	Digital Signal Processing Products
	Texas Instruments
	1992

Good luck.

> I have a new (Transtech) transputer-based system here, and would like
> to think about mixing in C40's in the future.  However, I don't know
> how various vendors are making this feasible.  Does TI have any info on
> its third-party supporters that would be mailable, or should one
> contact individual vendors first?

>From what I have heard there was one transputer company in the UK that
had a C40 on a TRAM, but they recently went bust.

Existing tranpsuter systems CAN be connected to C40 systems by
developing a C40 Communiction Port <---> Transputer Link interface. For
the hardware inclined, this is a relatively striaghtforward deisgn
exercise, although you would be advised to map a single transputer link
onto two C40 Communication Ports. The transputer link should be used in
a bi-directional mode and the C40 Communication Ports used in
uni-directional modes (one for each direction).

This interface is being developed for customers of our C40 systems
as a TIM-40 module with three transputer link interface connections and
will have the ability to propogate control signals (i.e. reset) between
the two systems. The interface is intended to be transparent although
the user would have to be concerned about packing and unpacking of
data, due to the C40 being limited to addressing data on 32-bit word
boundaries.

Regards,


Steve Bradshaw                 
Traquair Data Systems
Judd Falls Plaza, Suite 80      
Ithaca, NY 14850                

Phone: (607) 272 4417           
Fax:   (607) 272 4417
From: u9dmlb@ohm.york.ac.uk (Duncan McL Barclay)
Newsgroups: comp.sys.transputer
Subject: Re: occam
Date: 16 Aug 92 20:54:38 GMT
Organization: Electronics Department, University of York, UK

In <46@pine.ukc.ac.uk> arc1@ukc.ac.uk (tony) writes:


>In your opinion that is - this smacks too much of Orwellian
>overtones to me.  Why not let the programmer choose?
>Ok, it provides a standard layout, but open things up and
>let people decide over time what they want and they'll come
>up with a good working convention (or conventions) for
>layout.  I don't like having it enforced arbitrarily from
>on-high.

Hmm intersting, coz if you extend the 'on_high' argument why arent you
using your own programming language on your own system based on your own
VLSI process.

>Warren> Formatting a program in this way is good as one uses spacial relationships to indicate
>Warren> the programs structure.

>Not convinced.  Being forced into a particular layout
>doesn't, for me anyway, feel nice.  I'd like to learn what a
>good layout style is by getting it wrong, messy, learning
>from others etc.  It's a more constructive learning
>experience.

I agree, but if other people have done the messing about to find the
most natural way why not give it a try? In fact the OCCAM rules correspond to
my own preferred style of programming.

>Warren> , which cuts out the need of lots of end, od, esac, }
>Warren> and fi keywords.
>But they do make block encapsulation easier to see on the
>screen.

I disagree, fortunately or unfortuantely my first real programming experience
was in FORTRAN which has very few block ends etc, and one gets used to
seeing the structure of the code without the brackets, in fact one usually
blocks the code on the screen. When moving onto C etc I found the brackets
annoying, not only to type but because in some cases they are tacked
onto the end of a line or placed seperately, tracking down the end of
a block is hard. OCCAM makes it easier to see. 


-- 
Raggy                 | God smiles upon the little children, the alcoholics, and
u9dmlb@ohm.york.ac.uk | the permanantly stoned. S.King.
From: michael@uk.ac.oxford.robots (& Stevens)
Newsgroups: comp.sys.transputer
Subject: Re: Mixed C40/transputer networks & 3L Parallel C
Date: 19 Aug 92 20:39:30 GMT
Organization: Dept. Engineering Science, Oxford University, UK
In-reply-to: adc@threel.co.uk's message of 19 Aug 92 16:20:16 GMT

Just thought I would add my two pence worth to debate.

  Since 3L Parallel(ha ha) C never did support fine grained
parallelism I guess it doesn't matter too much what you run it on.
Transputer, C40, even 680x0 using semaphores and shared memory: it
would all be much the same. At least Inmos just call a C with a
process library "ANSI C" and make no claims for its parallel nature.

  Never having used a C40 (this being comp.sys.transputer) the
following questions come to mind.

1. Its a newer chip then a T8 and clearly faster, but it an actual
multiprocessing system do you get more bang per buck?

2. Is the architecture up to the job? Context switch time is just as
important as comunications speed. To get the much sort after linear
increase in performace

	Performance	|   /
			|  /
			| /
			|/
			|--------
				No of processors
each processor must be able to fill up all its available time. To do
this it must be able to quickly do something else while it waits for
other processors i.e. Context switch

--
Michael Stevens, Robotics Research Group,Dept of Engineering Science,Oxford,UK
INTERNET: michael@robots.oxford.ac.uk
From: bob@ida.dsir.govt.nz (Bob Valkenburg)
Newsgroups: comp.sys.transputer
Subject: Help with transputer operating systems
Date: 18 Aug 92 21:46:49 GMT
Organization: DSIR/IDA Auckland, New Zealand

Could somebody please give me some advice about available transputer
operating systems and which might be suitable for our purposes.

Here is a brief description of our setup which is primarily targeted at
machine vision applications.  Our system consists of several custom VME
based transputer boards running in a VME rack with Datacube pipeline
processing boards and an MVME 147 (68030) host CPU board.  We are using
the Microware  OS9 operating system. The transputers have only 1M of
standard  memory  and an additional 512K of shared memory (primarily
intended for images). One transputer (denoted TCM) is able to control
how the others access the shared memory and is able to set VME
interrupts and set up a C004 switch etc. I guess most of this information is 
irrelevant, the only significant point being that there is not
much memory available and we have some non-standard Hardware features
which we would like the operating system to control if possible. 

We have previously been developing code using the INMOS parallel C
toolset (the iserver was ported to OS9).

Some of the desirable characteristics we would like in our soon to be
purchased operating system are the following:

-  Real Time response.
-  Small (as only 1M of code memory is available).
-  Support for the  non standard facilities such as the registers to
   set up the access to shared memory.  I guess something analogous to a
   device driver is what I need here.
-  Compatibility with the sometime to be released T9000 
-  Some mechanism to support C004 switches 
-  some mechanism to support events
-  debugging support 
Note that these are only desirable properties probably only the 2nd one
is essential.

I am a little out of touch with what is currently available so any
advice would be appreciated.  Any appraisals/criticisms or comparisons of
the various operating systems would also be welcomed.

Many thanks 
Bob Valkenburg

Email bob@ida.dsir.govt.nz
Fax   +64-9-307 0618 
Newsgroups: comp.sys.transputer