HDTenEightyP/NetNews huggingface dataset:
From: lindsay@watnow.uwaterloo.ca (Lindsay Patten)
Subject: Re: IS Occam3 recursive?
Organization: University of Waterloo
Date: Tue, 17 Nov 1992 19:38:05 GMT

If it is considered reasonable to force the programmer to declare the
size of all arrays at compile time why isn't it reasonable to force
the programmer to declare the depth of recursion at compile time?

It seems to me that it would be better to take this approach than to
have all the programmers writing their own code to implement recursion
with all the wasted time and errors that involves.
-- 
Lindsay Patten
Pattern Analysis & Machine Intelligence Group         lindsay@pami.uwaterloo.ca
Dept. of Systems Design Engineering  {utai|decvax|uunet}!watmath!watnow!lindsay
University of Waterloo                   Neither I nor PAMI speak for the other
Newsgroups: comp.sys.transputer
From: brendan@buck.ac.uk (Brendan Murphy)
Subject: Re: Transputerlink -> Host throughput values
Organization: University of Buckingham
Date: Thu, 19 Nov 92 20:16:36 GMT

I am posting this to the group because it might be of general interest /
provoke some discussion...

In article <9211082963@gandalf.moria>, u31b3hs@pool.informatik.rwth-aachen.de 
(Michael Haardt) writes:

>I would like to know some "throughput" values of the transputer-host
>link.
>
>When I use iserver, writing 1k blocks to the host gives me a performance
>of about 20k per second.  Using smaller blocks results in very reduced
>performance.

What are you doing with the data on the host side - are you throwing it away
or writing it to disk?  Are you using standard i/o libraries?  If so, whose
libraries?

>I wrote a small program to measure only transfer speed by reading data
>directly from the link.  The maximum throughput was about 110k per
>second.  I think the difference results in iserver being a single
                                                            ^^^^^^
>threaded server, so it can't receive new packets while it processes
 ^^^^^^^^
>packets, which reduces performance a lot.

This is only part of the story.  A multi-threaded server per se doesn't buy
you any performance improvement; your client i/o libraries and server
communication protocol have to be multi-threaded too.

I have written a multi-threaded version of the iserver and I have changed the
SP protocol to include a process identifier field in each packet.  A simple 
asynchronous mux/demux process sits between the standard Inmos libraries and 
the server; the mux/demux needs the process identifier to know to which process
to return reply packets.  This environment removes the synchronous i/o 
bottleneck that is a limitation of standard transputer servers; for example, 
one transputer process can be doing file i/o while another is blocked doing a
keyboard read.  Overall utilisation of the server is therefore improved.  Even
so, one would need to write one's own multi-threaded i/o libraries in order to 
reap any performance benefits at the individual file descriptor level.

Brendan
-- 
********************************************************************************
Brendan Murphy					brendan%buck.ac.uk@uknet.ac.uk
Department of Computer Science			Tel: 0280 814080
University of Buckingham, MK18 1EG, UK		Fax: 0280 822245
********************************************************************************
Newsgroups: comp.sys.transputer
From: rob@pact.nl (Rob Kurver)
Subject: Re: Recursion in occam
Organization: PACT, Delft, The Netherlands
Date: Thu, 19 Nov 1992 12:48:08 GMT

In <142@autro1.UUCP> teig@autro1.UUCP (Oyvind Teig) writes:

>Recursion of occam-2 or -3

>I have seen enough of stack overflow errors to appreciate the lack
>of recursion in occam.

Recursion + stack-checking -> no stack overflow.

>Rob Kurver writes:
>> It is very well possible to introduce stack checking code during linking,
>> when a call-graph of the program can be used to determine if and when
>> it is possible.  This would result in ZERO overhead for a program written
>> without recursion, and minimum overhead for recursive programs.  We
>> are currently working on this feature in PACT Parallel C.

>Ok, but you still have not removed the stack overflow!

When I say "stack checking" I mean "stack checking plus expansion if
necessary".  By checking the stack and expanding it if necessary, you
remove the stack overflow.  The linker can build a call-graph for the
entire program, so it knows which functions call which other functions.
This allows it to detect recursion.  All non-recursive branches need
only have enough stack allocated once, at the start of the branch (i.e.
at process or program creation).  The recursive branches, if any, need
to have stack checking (+ expansion) code introduced in the loop
(unless you just want to restrict the depth at linktime, of course).

This way, there's no overhead if you don't use recursion, and there is
a small overhead if you do use recursion.  You don't have stack
overflows in any case.

>This comes close to the discussion of exception-handling: how do
>you solve that in Pact-C, and what would you recommend when stack overflow
>is encountered?

Upon stack overflow, the stack is extended by allocating a new block of
memory from the heap.  If this is not possible (out of memory), you get
a fatal error message and your program aborts.

>If occam had been written from the philosophy that "if you don't need it,
>don't use it", it definitively would have not been occam.

I guess it would not have been Occam-2, no.  It might have had data
structures :-).

>Is it possible to do multi-language design with the Inmos D7205 occam
>toolset and your Pact C-compiler, like it is with the Inmos C-toolset?

Yes.  You can link Occam (TCOFF) modules with PACT Parallel C modules.

>For me as an occam-user, your parallel C (:-) is of little interest because
>C is not interesting, if it were, I would not have used occam (recursive
>definition: interesting but little useful(%-|)

I C :-).  A lot of people do find C interesting, though.

>0yvind Teig
>Autronica, Trondheim, Norway

Rob

--
     PACT                   Rob Kurver
    Foulkeslaan 87         rob@pact.nl
   2625 RB Delft     ph: +31 15 616864 
  The Netherlands   fax: +31 15 610032
Newsgroups: comp.sys.transputer,comp.parallel
From: fabri@cassiopee.inria.fr (Andreas Fabri)
Subject: Sorting on the MeikoCS
Followup-To: comp.sys.transputer
Organization: INRIA Sophia-Antipolis, France
Date: 16 Nov 92 15:19:49 GMT

I am looking for implementations of sorting algorithms 
for the MeikoCS (M50).  


 Andreas Fabri
---------------------------------------------------------------------

 INRIA  Sophia-Antipolis                  email: fabri@sophia.inria.fr
 2004, Route des Lucioles BP 93           phone: (33) 93.65.77.72      
 06902 Sophia-Antipolis Cedex (France)    fax  : (33) 93.65.76.43


 Andreas Fabri
---------------------------------------------------------------------


Newsgroups: comp.sys.transputer
From: rpagan@rmece02.upr.clu.edu (Roque Pagan)
Subject: FFT OCCAM CODE WANTED !!!
Organization: UPR-Mayaguez--ASEL Lab
Date: Wed, 18 Nov 1992 17:31:59 GMT

	I'm trying to locate some FFT source code in OCCAM.  Any
    information would be greatly appreciated.

					Thanks in advance,

				------------------------------
					  ROQUE PAGAN

-----
	Roque	RPAGAN@rmece02.upr.clu.edu
Newsgroups: comp.sys.transputer
From: willi@informatik.uni-essen.de (Wilhelm Hasselbring)
Newsgroups: comp.sys.transputer
Subject: Broadcast on Transputers ?
Keywords: broadcast, transputer
Date: 19 Nov 92 10:01:39 GMT
X-Newsreader: Tin 1.1 PL4

I have a general question concerning transputer systems: Do there exists
operating systems or programming languages for transputer systems which
support broadcasting messages to all nodes in a net?

Thanks for your help, Willi

PS: I will summarize, if I get some replies.

--
-------------------------------
W Hasselbring, University of Essen              willi@informatik.uni-essen.de
From: friedman@starbase.trincoll.edu (Mark A. Friedman)
Subject: Transputer Development Environments for Sun Workstations
Reply-To: mark.friedman@trincoll.edu
Organization: Trinity College, Hartford, CT
Date: Wed, 18 Nov 1992 21:38:28 GMT

I am interested in information about any transputer development
environments for Sun workstations and will provide a summary of the
information I receive to the net.

We will be offering an upper-level, undergraduate course in Parallel
Computing Systems next semester and we are looking to purchase a
transputer kit to be installed within a Sparc II workstation with
supporting software.  We will be working within a small budget
($8,000-10,000) this year but plan to expand the system in future
years.

Our immediate concern is to obtain a system that is suitable for
demonstating the rewards/possibilities/limitations of parallel
implementations to our undergraduate students and secondly to be used 
in faculty research as well.  Versatility and perhaps, a greater number
of less powerful/less expensive processors would be more suitable than
a system with fewer more powerful processors.  In future years, we
will look to expand the computational power of the system.

Any recommendations or information to get us looking in the right
directions would be appreciated including:

	- US distributors (phone/addresses/email) of transputer
		systems.
	- suggestted configurations within our budget that match our
		goals.
	- materials to be used in our future course.

Thanks in advance.

-- Mark
--


Professor Mark A. Friedman		 mark.friedman@trincoll.edu
Engineering and Computer Science	 (or friedman@starbase.trincoll.edu)
Trinity College				 Phone: (203) 297-2519
Hartford, Connecticut   06106		 Fax: (203) 297-2569
Newsgroups: comp.sys.transputer
From: michael@gandalf.moria (Michael Haardt)
Subject: Summary: Transputerlink -> Host throughput values
Reply-To: u31b3hs@pool.informatik.rwth-aachen.de (Michael Haardt)
Organization: An old and gray machine, somewhere in Moria.
Date: Wed, 18 Nov 92 14:45:01 +0100
Return-Path: <u31b3hs@pool.informatik.rwth-aachen.de>

My original article:

|> I would like to know some "throughput" values of the transputer-host
|> link.
|> 
|> When I use iserver, writing 1k blocks to the host gives me a performance
|> of about 20k per second.  Using smaller blocks results in very reduced
|> performance.
|> 
|> I wrote a small program to measure only transfer speed by reading data
|> directly from the link.  The maximum throughput was about 110k per
|> second.  I think the difference results in iserver being a single
|> threaded server, so it can't receive new packets while it processes
|> packets, which reduces performance a lot.

My machine is a 386-20 without cache, I use a B004 compatible board without
interrrupts.  The machine has about 4500 dhrystones.

From: Bob Green <bob@inmos.co.uk>

> Even if iserver were multi-threaded, that wouldn't help, since when the iserver
> protocol was invented, it was specified as being synchronous. i.e. an application
> won't even attempt to submit a second request until a reply to its first request
> has been received.

True, a asynchronous protocol would be needed for a multi-threaded
server.  Of course that requires more complicated software at the
transputer side, too.

From: Charles Francois  <Charles.Francois@sophia.inria.fr>

> ...                         We had 6 transputers for that purpose,
> that were bound to a Sun3/140 via VME 8/32 (B014 from INMOS). Is it
> the one that you are using?  I modified the iserver from INMOS to
> make it work over the Ethernet, so that the transputer network
> would be accessible from a Sparcstation for example.  There was no
> other procress running on the Sun3/140, apart from the usual
> deamons.  Well, the best I could get was about 40Kbytes/sec.
> ...                              I think that there is no miracle
> to be expected from this board, and I was told that it is a general
> complaint.  For fast transfer, maybe you should consider the B016
> (which as 4M of shared memory) or the B300 (direct interface to
> Ethernet).

As it seems, iserver isn't best choice if you have to transfer big
amounts of data between host and transputer.  The only easy tuning which
could be done is modifing the iserver protocol to allow bigger packets,
because my benchmarks showed that there were huge differences between
e.g. 512 and 1024 user data packets.  Of course that doesn't help if
the problem forbids blocking.

For high performance, either i/o devices should be directly connected to
a transputerlink or you use at least your own problem specific protocol.

Michael
Newsgroups: comp.sys.transputer
From: R.J.Patel@massey.ac.nz (R. Patel)
Subject: Help/Advice/Contacts for CSA T800
Organization: Massey University, Palmerston North, New Zealand
X-Reader: NETNEWS/PC Version 2c
Date: Mon, 16 Nov 92 22:09:13 GMT


G'day,

I'm will be working on eight CSA T800 transputers over the next eleven
weeks, programming in 3L Parallel FORTRAN, and I would be much obliged
if
anyone out there could give me some tips and provide me with some
assistance
during this period.

The transputers are going to be used to process genetic data for
evolutionary
tree purposes using the great deluge.

As a complete novice in the area of transputers any assistance would be
much appreciated.
From: jeremy@cs.adelaide.edu.au (Jeremy Webber)
Newsgroups: comp.sys.transputer
Subject: Re: IS Occam3 recursive?
Date: 24 Nov 92 08:42:41
Organization: Digital Arts Film and Television
	<1992Nov17.093335.11067@inmos.co.uk> <rob.722005143@dutncp8>
NNTP-Posting-Host: chook.cs.adelaide.edu.au
In-reply-to: rob@pact.nl's message of Tue, 17 Nov 1992 12:59:03 GMT

It seems that this argument has degenerated into two camps: those who
think Occam is more "reliable" than C because it doesn't have recursion,
and those who need to use recursion and therefore program in C (does
anyone use Pascal on the Transputer?)

The reason lack of recursion makes Occam more "reliable" seems to be
that the proponents of this argument can't think of a decent way to
allocate memory on a fixed-memory machine.  Given that many of these
proponents come from Inmos perhaps that explains why Inmos C handles
memory resources so badly...

For my own experience, I ported a largeish application from Occam to C,
still on the Transputer.  The result ran about the same speed, even
though the C compiler seems to generate code which runs much slower than
the Occam compiler.  The compensating factor was in algorithm
improvements made possible by the improved expressability of C.  The
result as also *much* more reliable than its Occam predecessor as I had
been able to remove large chunks of code which were only necessary in
the older system to get around the limitations of Occam, and could thus
devote my effort to improving the system instead of working around the
compiler.

	-jeremy

--
--
Jeremy Webber			   Internet: jeremy@cs.adelaide.edu.au
Digital Arts Film and Television,	     jeremy@chook.ua.oz.au
1 Ledger St, Beverley, SA 5009,       Phone: +61 8 347 4691
Australia			        FAX: +61 8 347 4692
Newsgroups: comp.sys.transputer
From: 890681b@dragon.acadiau.ca (Robin B. Blondon)
Subject: Looking for OCCAM code
Organization: Acadia University
Distribution: na
Date: Sun, 22 Nov 1992 19:22:42 GMT

I am currently trying to learn OCCAM.  I am trying to get ahold of some
sample OCCAM programs to speed my learning (I have only limited access
to a book on OCCAM so I would like some programs to browse though while
I don't have access to the book).  I was wondering if anyone knows the
location of an ftp site carrying programs written in OCCAM source code.
Also, if anyone happens to have some spare OCCAM programs lying around
I would appreciate it if some could be EMailed to me.  I am particularly
interested in programs which deal with arrays and matrices and exploit
parallel features of the language.

My EMail address is: 890681b@dragon.acadiau.ca

Thanks.

 - Robin

-- 
-----------------------------------------------------------------------------
Robin B. Blondon
EMail : 890681b@dragon.acadiau.ca
-----------------------------------------------------------------------------
Newsgroups: comp.sys.transputer
From: Jouni Ryn| <Jouni.Ryno@fmi.fi>
Subject: Transputer & DSP & radiation ?
X-Xxmessage-Id: <A73667AFF1013285@jar.fmi.fi>
X-Xxdate: Mon, 23 Nov 92 10:49:19 GMT
Organization: Finnish Meteorological Institute
X-Useragent: Nuntius v1.1.1d11
Date: Mon, 23 Nov 92 08:28:57 GMT

I would like to know, if anyone has any reference on using transputers
with digital signal processor in high radiation field. ( max 20 Krad).
Has the IMS B420 vector prosessing TRAM tested for radiation (references
?) Since it doesn't use links for communicationg with the transputer
(links don't stand radiation), it might work, but how is the SRAM or can
it be replaced with some other tolerant memory.
Have the OCCAM interfaces for the B420 released, IMS F000 ( they are
'promised' in the future ( in 1991 edition of the transputer development
and iq systems databook )

       Jouni Ryn|                            Tel. (+358)-0-1929508
       Finnish Meteorological Institute      TLX 124436 EFKL SF
       Department of Geophysics              TFAX (+358)-0-1929539
       P.O.BOX 503                           Internet: Jouni.Ryno@fmi.fi
       SF-00101 Helsinki                     AppleLink: SF0129
Newsgroups: comp.sys.transputer
From: rpagan@rmece02.upr.clu.edu (Roque Pagan)
Subject: FFT OCCAM CODE WANTED (CORRECTED) !!!
Organization: UPR-Mayaguez--ASEL Lab
Date: Wed, 18 Nov 1992 18:03:46 GMT

	I'm trying to locate some FFT source code in OCCAM.  Any
    information would be greatly appreciated.

					Thanks in advance,

				------------------------------
					  ROQUE PAGAN

-----
	P.D.
		In the previous article some mistakes were introduced.
	The e-mail should be:
			rpagan@rmece02.upr.clu.edu

-----
		  CENTER FOR APPLIED REMOTE SENSING
		   	 AND IMAGE PROCESSING

	   	     SIGNAL PROCESSING LABORATORY

	               University of Puerto Rico
	      Electrical and Computer Engineering Dept.
 		           Mayaguez Campus
From: teig@autro1.UUCP (Oyvind Teig)
Newsgroups: comp.sys.transputer
Subject: Recursion in occam
Date: 19 Nov 92 09:18:37 GMT
Reply-To: teig@autro1.UUCP (Oyvind Teig)
Organization: Autronica A/S, Trondheim, Norway

Recursion of occam-2 or -3

I have seen enough of stack overflow errors to appreciate the lack
of recursion in occam.

Rob Kurver writes:
> It is very well possible to introduce stack checking code during linking,
> when a call-graph of the program can be used to determine if and when
> it is possible.  This would result in ZERO overhead for a program written
> without recursion, and minimum overhead for recursive programs.  We
> are currently working on this feature in PACT Parallel C.

Ok, but you still have not removed the stack overflow!

This comes close to the discussion of exception-handling: how do
you solve that in Pact-C, and what would you recommend when stack overflow
is encountered?

If occam had been written from the philosophy that "if you don't need it,
don't use it", it definitively would have not been occam.

Is it possible to do multi-language design with the Inmos D7205 occam
toolset and your Pact C-compiler, like it is with the Inmos C-toolset?

For me as an occam-user, your parallel C (:-) is of little interest because
C is not interesting, if it were, I would not have used occam (recursive
definition: interesting but little useful(%-|)

0yvind Teig
Autronica, Trondheim, Norway
Newsgroups: comp.sys.transputer
From: steved@phoenix.inmos.co.uk (Stephen Doyle)
Subject: Re: OCCAM/C various
Reply-To: steved@inmos.co.uk (Stephen Doyle)
Organization: INMOS Limited, Bristol, UK.
Date: Thu, 19 Nov 1992 17:01:58 GMT

In article <rob.722124411@dutncp8> rob@pact.nl (Rob Kurver) writes:
>In <1992Nov18.130407.12799@titan.inmos.co.uk> steved@lion.inmos.co.uk (Stephen Doyle) writes:
>
>...  Although customer
>feedback indicates people eventually forget about Occam as they find
>they can do everything they want in PACT Parallel C.
>
You are rather trivialising OCCAM to syntax for creating/using processes and
channels, there is much more than this to the language, a C environment 
simply does not provide the semantics, compile and run-time checking, 
formal proving or transformation methods that you get with OCCAM. OCCAM is
a popular language and is not losing popularity, you can rewrite an 
application in obfuscated C but it bears only a passing resemblance to 
OCCAM. I still echo the sentiment of many customers who like to use the
benefits of both.

>I've seen benchmark results of the beta version of your new optimizing C
>compiler, ...

Aren't benchmarks wonderful, so subjective! 

Just as well there are so many other goodies in the package then!

> ... email me for details

Likewise

Steve


Steve Doyle, Software Marketing, INMOS Ltd   | Tel +44 454 616616
1000 Aztec West                              | 
Almondsbury                                  | UK: steved@inmos.co.uk
Bristol BS12 4SQ, UK                         | US: steved@inmos.com
From: wayne@stan.xx.swin.oz.au (Wayne Cosshall)
Newsgroups: comp.sys.transputer
Subject: Afserver vs. Iserver?
Summary: What are the differences between the 3L Afserver and the inmos Iserver
Keywords: afserver, iserver, transputer, software
Date: 24 Nov 92 06:02:13 GMT
Organization: Comp. Centre, Swinburne University of Tech., Melbourne, Australia

I would like to know what the differences are between the 3L Afserver
and the Inmos Iserver?

We are interested in writing an Afserver? compatible program to support
DSP based systems.  Hopefully this will enable transputer programs to be
easily ported, etc.

Can the Iserver be used in place of the Afserver, or visa vera?

Thanks

Wayne J. Cosshall
Dept. of Computer Science
Swinburne University of Technology
Australia
wayne@saturn.cs.swin.oz.au
Newsgroups: comp.sys.transputer
From: Marco Kesseler <marcok@cs.kun.nl>
Subject: Re: IS Occam3 recursive?
Organization: University of Nijmegen
X-Useragent: Nuntius v1.1
     <Bxuxz5.F0E@cs.bham.ac.uk> <1992Nov18.130407.12799@titan.inmos.co.uk>
     <rob.722124411@dutncp8>
Date: Thu, 19 Nov 1992 10:43:15 GMT

In article <1992Nov18.130407.12799@titan.inmos.co.uk> Stephen Doyle,
steved@lion.inmos.co.uk writes:
>I guess the 
>difference boils down to whether you want an ANSI C validated compiler
with 
>functional additions for parallelism and communications or an ANSI C
compiler 
>with non-ANSI language additions for the same. I would argue (from
customer 
>feedback) that OCCAM tends to be used along with INMOS ANSI C as this 
>provides you with a flexible environment for parallel/comms/sequential 
>programming with excellent diagnostics at compile and run time.
>
>Just to cloud the issue once more INMOS' soon to be shipping new
optimising C 
>compiler has a specific optimisation for tail call recursion i.e.
>
>void p (int q)
>{
>  ...
>  return(p(...));
>}
>
>in this case the workspace of p is reused as the function recurses,
also, 
>nested returns are omitted so that only one return is needed no matter
how many 
>levels of recursion take place.

The compatibility issues mentioned above make me wonder if such
an 'optimisation' is conform ANSI standards. Forgive me my ignorance,
but would such a procedure work in any implementation of ANSI C?
It guess this is a new feature of C. Perhaps a rather superfluous
thing to do as well. C has loops.

By the way, we are implementing a lazy functional language (Concurrent
Clean) on the transputer. The way to write loops in such a language is
by means of recursion as depicted above (there is no other way). Needless
to say that we have implemented this kind of 'optimisation'.

Marco