HDTenEightyP/NetNews huggingface dataset:
From: conor@lion.inmos.co.uk (Conor O'Neill)
Subject: Re: occam
Reply-To: conor@inmos.co.uk (Conor O'Neill)
Organization: INMOS Limited, Bristol, UK.
Date: Wed, 12 Aug 1992 11:53:12 GMT

This is the official INMOS position on occam development.

PLEASE do not e-mail me about this; I am too busy.

INMOS OCCAM POSITION
====================

13th May 1992.

INMOS are fully committed to supporting the occam programming language,
and believe that for important classes of application occam 2 is the best
language for its customers to use.

The advanced development tools including an X-windows based debugger,
a profiler and a message routing configurer will all support occam 2
programming.

An occam 2 toolset for the T9000 will be available when the T9000 is available.
This will be exactly source compatible with the occam 2 system in the current
occam 2 toolset.  At the configuration level only the hardware description
will need changing to describe the T9000 hardware, the rest of the
configuration description will be exactly the same.

INMOS expects to release an optimising occam 2 compiler with full dataflow
optimisations in 1993.  In this release the occam 2 language will be
extended to support the following new features :-

 - User defined types
 - Records
 - Remove requirement for explicitly typing literals
 - Allow arithmetic on BYTE types
 - Allow FUNCTIONs to return fixed length arrays
 - Permit the dropping of FROM and FOR in segments of arrays

This represents the first phase of the occam 3 development based on
Geoff Barrett's draft language specification.

INMOS is also planning a longer term compiler development programme based on
ANDF technology.  A second phase of development addressing modularity
and sharing will be undertaken in the context of this development and will
lead to the availability of native occam 3 compilers for a wide range of
different computer architectures.

Signed: Ian Pearson, David May, Tony Debling.


---
Conor O'Neill, Software Group, INMOS Ltd., UK.
UK: conor@inmos.co.uk		US: conor@inmos.com
"It's state-of-the-art" "But it doesn't work!" "That is the state-of-the-art".
Newsgroups: comp.sys.transputer
From: desprez@schnaps.ens-lyon.fr (Frederic Desprez)
Newsgroups: comp.sys.transputer
Subject: T9000 machines projects?
Date: 14 Aug 92 07:47:56 GMT
Reply-To: desprez@schnaps.ens-lyon.fr (Frederic Desprez)
Organization: Ecole Normale Superieure de Lyon, France


	Hi,

	I'm looking for informations about projects of parallel 
	machines using T9000 processors and C104 routing chip.

	I only have some informations about Parsytec's Giga Cube.

	Thanks in advance.

	Frederic
Newsgroups: comp.sys.transputer
From: cprem@marlin.jcu.edu.au (Ross E Milward)
Subject: CDL Topologies
Organization: James Cook University
Date: Mon, 17 Aug 92 06:45:45 GMT

I've been trying to set up some topologies on our transputer system
using CDL but am having a couple of problems with the definitions.
I was wondering if someone could help me out?

I'm trying to create a  bi-directional ring such as:

	C = W = W 
        ||	||
    	W = = = W
			where C represents a controller process and
			      W represents the worker processes.

I know how to create a uni-directional ring, but am unsure of how 
to connect the controller process (which handles the input/output)
to the workers in the above topology.

Thanks,
Ross.

-- 
Ross Milward,   ross@coral.cs.jcu.edu.au, cprem@marlin.jcu.edu.au
Honours Student - Comp. Sci. Dept.,  James Cook Uni, Qld, 4811, Australia.
"The way the rain comes down hard, that's how I feel inside." - The Cure
Newsgroups: comp.sys.transputer
From: rob@pact.nl (Rob Kurver)
Subject: Re: Why should you consider using occam?
Organisation: PACT, Delft, The Netherlands
Organization: Delft University of Technology
Date: Tue, 18 Aug 1992 12:16:57 GMT

In <1992Aug14.155639.1045@EE.Surrey.Ac.UK> R.Peel@ee.surrey.ac.uk (Roger Peel) writes:

>So why is occam not liked by so many programmers?  Well, some write
>sequential code for which occam only provides a few extra benefits.  Fine
>- they can justifiably continue to use a sequential language provided they
>only attempt to run their code on a single transputer.  Parallel
>enhancements to a sequential language might be acceptable for particularly
>large-grained parallel tasks, too, but this is not where occam stands out,
>either.

I tend to agree insofar as Roger is referring to sequential languages with
library support for parallel processing added.  Such function calls don't
provide the necessary level of abstraction for fine-grain parallelism,
and often cause an unacceptable overhead.

Now, without wishing to get dragged into yet another religious discussion
about programming languages or editors, I feel that I must point out
that the PACT Parallel C compiler has language extensions very similar
to those found in Occam (par, alt, channel) folded into ANSI Standard C
in a natural manner.  This allows fine-grain parallelism to be expressed
just as easily as in Occam.

I agree with Roger that many communicating lightweight threads, buffers,
multiplexers etc., combined with a clean and powerful syntax to describe
them makes for a very nice programming model indeed.  This model is now
accessible to both Occam and C programmers alike.

Best,

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
From: k3mi@jupiter.sun.csd.unb.ca (Brian d'Auriol)
Subject: Re: occam
Organization: University of New Brunswick
Date: Wed, 12 Aug 1992 13:32:16 GMT

In article <2490@news.cerf.net> jcbhrb@nic.cerf.net (Jacob Hirbawi) writes:
>(3) Is it really elegant to write this:
>
>     IF
>       var1 < 1.0 (REAL32)
>         SEQ
>           var1 := 2.0 (REAL32)
>           var2 := 2.0 (REAL32)
>       TRUE
>         SKIP
>
>     instead of  If( var1 < 1.0 ) Seq{var1 = 2.0;var2 = 2.0;}
>
>Don't get me wrong; Occam has many innovative features; it just seems to
>me that a more sophisticated parser for the syntax would have gone a long
>way towards making it more popular -- and a long way towards keeping
>irritable people like me quieter ;-) .
>     

Ok, but I would ***MUCH*** rather the first syntax for a folding editor.
see below....

     IF
       var1 < 1.0 (REAL32)
         ...  process XYZ
       TRUE
         SKIP

     ...  an if with no idea of *structure*

In general the IF follows the syntax of a tagged protocol.  In both cases,
the following is very easy to read.

     IF
       condition 1
         ...  proc 1
       condition 2
         ...  proc 2
       condition n
         ...  proc n
       guard
         ...  proc guard


In short, I wonder if the extended syntax of Occam (esp. not free formatted)
assists in the coding with a folding editor.
Brian d'Auriol
From: siegl@RISC.UNI-LINZ.AC.AT (Kurt Siegl)
Newsgroups: comp.sys.transputer
Subject: Re: Why no mailings ?
Date: 13 Aug 92 13:08:06 GMT
Distribution: world
Organization: The Internet


In message <13 Aug 1992, 11:14:08 TPM@uk.ac.rl.ib> Terry MAWBY writes:
>
>A while back there were some serious problems somewhere between Bonn, RAL, and
>Cornell which resulted in messages either disappearing in to a black hole or
>else being distributed several times.
>
>It would be nice to know if the system is now behaving itself; I for one dont
>want to put things up that dont get distributed or make it look as though
>I've got my finger stuck on the 'send' key, much to everyones annoyance.
>
>Terry Mawby
>Informatics Department, RAL, Chilton, DIDCOT, Oxon, OX11 0QX
>tpm@uk.ac.rl.inf  / 0235 44 57 87

A serious problem for the transputer mailing list readers is that
all mails sent to the transputer mailing list are automatically forwarded
to the comp.sys.transputer Newsgroup but not in reverse direction.
So many peoples only follow up to the Newsgroup which leads to the impression
that mails disappers in the net for members of the mailing list.

Is it possible to reorganize the mailing list in a proper way that we receive
also follow-ups from the Newsgroup?

Kurt

----------------------------------------------------------
You can tell how far we have to go, when FORTRAN is the language of
supercomputers.    -- Steven Feiner
----------------------------------------------------------
Kurt Siegl / RISC, University of Linz, Austria
email: siegl@risc.uni-linz.ac.at
Tel:   *(7236)3231-66      Fax: *(7236)3338-30
From: wgd@ukc.ac.uk (W.G.Day)
Newsgroups: comp.sys.transputer
Subject: large granularity & going all the way (was: Y should U consider occam?
Date: 19 Aug 92 09:48:02 GMT
Reply-To: wgd@ukc.ac.uk (Warren Day)
Organization: Computing Lab, The University, Canterbury, Kent. CT2 7NF, UK

This article is in two parts, both are questions, the former being more of
a discussion.

In <1992Aug14.155639.1045@EE.Surrey.Ac.UK> Roger Peel writes:
Parallel
enhancements to a sequential language might be acceptable for particularly
large-grained parallel tasks, too, but this is not where occam stands out,
either.

In article <rob.714140217@dutncp8> rob@pact.nl (Rob Kurver) writes:
Such function calls don't
provide the necessary level of abstraction for fine-grain parallelism,
and often cause an unacceptable overhead.

In what way isn't occam good at large-grained parallelism?
Is the due to the machinery that has to be built to set up a pipeline,
geometric distribution or a processor farm?
The first two can be built simply, though without a great deal of efficiency.

Though there is an equivalent weakness in the data structure side of
programming languages.  Linked lists and binary trees are effectively large
grain data structures and we have to continually build and re-build those.

Rob again:
This allows fine-grain parallelism to be expressed just as easily as in Occam.

Does it have the compilation checks too?

>Best,

>Rob

Warren
Newsgroups: comp.sys.transputer
From: duha@rekpmx.biomed.mcgill.ca (Jan A. Duha)
Subject: Questions from a Novice
Summary: Help!!!
Keywords: T805, INMOS Ansi C
Organization: Neuromuscular Control Lab
Date: Fri, 14 Aug 1992 16:03:00 GMT

Greetings!

  We recently purchased a PC-based transputer system consisting of two
T805 trams, along with a/d and d/a trams from Sunnyside Systems; we are
developing a real-time control system (using the INMOS Ansi C Toolset) for a 
hydraulic actuator used in motor control studies.  This is my first exposure 
to Transputer programming, and I'm appalled at the (apparent?) lack of 
documentation on INMOS Ansi C.  Granted, the examples which came the the C 
compiler DID help somewhat, but they did not explain the whole story.  The 
local INMOS dealers claimed there are no books on Parallel C!  With this in 
mind, I turn to any  experts out there, with a few burning questions:

1) the Ansi C user manual mentions that all Channels must be initialised
   before use:  is this true even for single channels (not arrays 
   of channels) when they are defined in .cfs files?  (There are examples 
   on the Ansi C disks which DON'T use ChanInit with single channels defined
   in configuration files; and all the programs I've written in the same
   manner seem to work fine.)

2) It seems to me that the "Proc" family of functions are only useful for
   defining procedures running in parallel on the SAME TRANSPUTER, since
   for a network it's much easier to combine and place several linked 
   units using the configuration language.  Is there an advantage to
   using "ProcPar" ?  Am I missing something?

3) What kind of handshaking goes on during the transfer of a single byte
   over a channel?  How long should this transfer take?  It seems to me
   that channel transfers are a bottleneck in my programs... should this
   be the case?

 Please excuse my ignorance, but I REALLY need your help on this.

Many thanks in advance,

Jan Duha
duha@rekpmx.biomed.mcgill.ca
duha@ee470.ee.mcgill.ca

Neuromuscular Control Lab
Department of Biomedical Engineering 
McGill University
Montreal, Canada
514-398-6734
From: ian@buckingham.ac.uk (Ian East)
Newsgroups: comp.sys.transputer
Subject: Transputer/Mac
Date: 13 Aug 92 08:16:27 GMT
Distribution: world
Organization: The Internet



Anyone else out there using Transputers with the Mac? Would be interested in
hearing from you (equipment, servers etc.).

Paratech Solutions have ceased trading (in that form at least). This does not
mean the death of TMac, the SCSI-hosted Mac transputer board. I intend
upgrading the server (TServer) to incorporate Apple Events, to support scripting,
Communications Toolbox, to improve terminal emulation, and graphics protocol in
the near future.

Craig Davidson was kind enough to point out that TOTAL access to the Mac HCI is
extremely cheap and easy using MacWorkstation, which defines its own protocol.
This may be the best means available to compose transputer applications with
a modern WIMP HCI.

Anyone, particularly in the UK, interested in Mac transputer access please
contact me.

Lastly, anyone else interested in obtaining a Mac native occam compiler?

Ian East
University of Buckingham, UK
ian%buck@uk.ac.ukNet

PS Why is it so quiet out there? Is there another secret mailing list?
From: adc@threel.co.uk (Alan "D." Culloch)
Newsgroups: comp.sys.transputer
Subject: Mixed C40/transputer networks & 3L Parallel C
Date: 19 Aug 92 16:20:16 GMT
Organization: The Internet

> 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?

Our 3L Parallel C product supports mixed networks of transputers and C40s. 
Tasks can be booted onto C40s through a network of transputers, and vice
versa.  A transputer task can talk to a task running on a neighbouring
C40 using the same chan_out_message/chan_in_message functions as usual. 

These facilities obviously depend on the transputer links being mated to
the C40 communication ports via a hardware interface as described in
Steve Bradshaw's posting.

I have an application note from Mark Bell at Hull University which
describes the design of such a link bridge.  They have used it to
connect two TIM-40 C40 modules on a Hunt Engineering motherboard to an
existing T800-based measurement and control system.  The C40s were used
to speed up the control loop processing.  The paper describes some
pretty impressive performance gains.  It has been submitted for
publication in TI's upcoming C40 Application Databook; contact me if you
would like a copy of the paper.

Another mixed C40/transputer application I know of uses Hema
Elektronik's DSP1 C40 board, which has an on-board C40 comms port to
T800 link adapter.  Their client's application was optical surface
inspection in manufacturing quality assurance.  This application and
several others are described in a paper on "Initial Applications of 3L
Parallel C for the C40" which I will be presenting at PACTA'92 in next
month in Barcelona.  Again, contact me if anyone wants a copy.


> Is there a list of current vendors who are offering support (hardware
> and software) for the C40?

3L Parallel C for the C40 currently supports these development boards:

* ASPI Vortex
* DSP Research TIGER-40 
* Hema DSP1
* Hunt Engineering HEPC2
* Loughborough Sound Images/Spectrum DPC/C40
* Transtech TDB416

Support is under development for, among others:

* Ariel V-C40 Hydra
* Sang Computersysteme Mega-Link C40-AT
From: traff@diku.dk (Jesper Larsson Traff)
Newsgroups: comp.sys.transputer
Subject: Re: icc-buglist available?
Date: 13 Aug 92 13:23:16 GMT
Organization: Department of Computer Science, U of Copenhagen

str@mab1.iitb.fhg.de (Struck) writes:

>In <JAN.92Aug10175954@pallas.neuroinformatik.ruhr-uni-bochum.de>
>Jan Vorbrueggen writes:

>>Beat hard upon your distributor  there is a public, published bug list
>>from INMOS for all their software products.

>As we use the INMOS icc since December 1991, I would like to know,
>how to get the buglist for this compiler. Does anyone have the current
>list?

We would be *VERY* interested as well. Does anybody have this list in 
electronic form?


Jesper Larsson Traff
DIKU - Dept. of Computer Science, University of Copenhagen
Denmark

-- 
Jesper Larsson Tra:ff --- *everything* ... at (currently): 

DIKU - the Department of Computer Science, University of Copenhagen, Denmark
..... and elsewhere
Newsgroups: comp.sys.transputer
From: michael@gandalf.moria (Michael Haardt)
Subject: Re: Wanted: Cross-Assembler
Reply-To: u31b3hs@pool.informatik.rwth-aachen.de (Michael Haardt)
Organization: Moria
Date: Fri, 14 Aug 92 01:07:45 +0100
Return-Path: <u31b3hs@pool.informatik.rwth-aachen.de>

In article <1992Aug12.180029.1143@gdr.bath.ac.uk>, mapsajw@gdr.bath.ac.uk (S A J Winder) writes:
> 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.

I am working on such a thing and still looking for beta testers.  It is
an assembler and linker, the linker creating code to start at a specific
address.  A small disassembler is included.  I use m4 as macroprocessor.
The assembler doesn't understand floating point constants yet.  It may
still contain bugs, so you are warned...

The whole thing is written in ANSI C and should be quite portable.

Michael
From: bane@vtx.ma.man.ac.uk) (M i c h a e l ;-)
Newsgroups: comp.sys.transputer
Subject: Re: occam
Date: 12 Aug 92 13:20:41 GMT
Reply-To: bane@vtx.ma.man.ac.uk
Organization: Magic Michael's Mushroom Factory.

In article <JAN.92Aug12103429@pallas.neuroinformatik.ruhr-uni-bochum.de>, jan@pallas.neuroinformatik.ruhr-uni-bochum.de (Jan Vorbrueggen) writes:

|>    > On a similar note the TDS, like every new and elegant code managing tool;
|>    > once one is fluent with it's workings, has its own continually growing set
|>    > of advantages over traditional editors.
|> 
|>    I think I'll complain about this one too :)
|> 
|>    TDS is not a bad tool; it does have a reasonably good editor and file management
|>    system. My objection is why?. Who needs a new editor?; I mean just how many 
|>    ways can you do a cutandpaste operation!. Personally I like to keep the
|>    option of using any editor I wish (this may ore may not be origami) and I 
|>    like to have more direct control over the files on my disk. As soon as the 
|>    toolset came out, I gladly converted away from the TDS.
|> 
|> Actually, I think the control of disk files is what the TDS does best. When
|> 
|>  Jan Vorbrueggen
|>  jan@neuroinformatik.ruhrunibochum.de



Really??? Admittedly, I use OPS (Meikos' version of TDS) but the number of times that
I've lost files (yes, complete files) due to OPS being unable to update a file (eg due
to the underlying filestore being full) has been really really annoying!!!

And wouldn't it be great to be able to jump to exactly where you wanted in the 24th
nested fold (in one go)!


Now, who wants to inform me a bit more about this toolset....

Michael
Newsgroups: comp.sys.transputer
From: k3mi@jupiter.sun.csd.unb.ca (Brian d'Auriol)
Subject: occam3
Organization: University of New Brunswick
Date: Fri, 14 Aug 1992 14:02:45 GMT

Does anyone have the reference for the paper on Occam 3.  I believe that
is was discussed some time ago on the network, but I don't remember.  Better,
would anyone offer to send me a copy?

Brian d'Auriol
From: rms@well.sf.ca.us (richard marlon stein)
Newsgroups: comp.sys.transputer
Subject: Re: T9000 status
Date: 18 Aug 92 00:00:26 GMT
Organization: Whole Earth 'Lectronic Link



In article <24973.9208171506@lion.inmos.co.uk> steved@inmos.co.uk (Stephen Doyle) writes:
>in Article 2466 of inmos.lists.transputer PVR@autoctrl.rug.ac.be
>(Patrick Van Renterghem) 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. 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.
>
W.J. Dally's (MIT) message driven processor -- the jelly-bean machine
appears to emulate the transputer in several ways: low context switch time
(from multiple register sets), message-passing links (dead-lock free) @
20 Mbytes/sec.  The catch: he has a translate instruction that eases
address translation in a global shared memory structure.  I can't say
that I necessarily support all of the COSMOS software architecture as
a commercially viable PRAM model though.

-- 
Richard Marlon Stein, Internet: rms@well.sf.ca.us
To those who know what is not known;  The Chronicles of Microwave Jim!
From: jan@pallas.neuroinformatik.ruhr-uni-bochum.de (Jan Vorbrueggen)
Newsgroups: comp.sys.transputer
Subject: Re: occam
Date: 13 Aug 92 04:37:18 GMT
	<JAN.92Aug12103429@pallas.neuroinformatik.ruhr-uni-bochum.de>
	<1992Aug12.124107.19492@jupiter.sun.csd.unb.ca>
Organization: Inst. f. Neuroinformatik, Ruhr-Universitaet Bochum, FRG
In-reply-to: k3mi@jupiter.sun.csd.unb.ca's message of 12 Aug 92 12:41:07 GMT


   Am I missing the point here, but, there is a utility in the latest version
   of the Occam toolset (also in the latest version of the c toolset and if
   I remember, is also in the D705 product)ANYWAY: the utility is called
   imakef and builds a makefile (complete with all necessary dependencies).  It
   does this by backtracking from the desired .btl/.b8h/etc. to all .occ/.pgm 
   files.   

The slave work is required in spite of imakef trying to give you a first
cut  but that first cut is very rough and needs extensive hand editing,
so when you make any additions/changes, it's not feasable to just run imakef
again. We're talking here of a programme, of course, that has 3 different
programmes, each consisting of a halfdozen processes, all accessing elements
of about a dozen libraries (not counting system libraries). imakef, for
instance, can't figure the libraries out, and how could it, they're arbitrary
anyway.

'nuff said.

While we're at it: Thanks for the official Inmos statement of occam's future.
I especially applaud the development decisions (what to implement first, etc).
Two little questions reamin, however: How optimising do you expect the
compiler to be (e.g. compared with the ACE compilers), and could the delivery
date of 1993 be narrowed a little? Thanks.

 Jan Vorbrueggen
 jan@neuroinformatik.ruhrunibochum.de
Newsgroups: comp.sys.transputer
From: steved@inmos.co.uk (Stephen Doyle)
Newsgroups: comp.sys.transputer
Subject: re: T9000 status
Date: 17 Aug 92 15:06:00 GMT
Distribution: world
Organization: The Internet

in Article 2466 of inmos.lists.transputer PVR@autoctrl.rug.ac.be
(Patrick Van Renterghem) writes:

>I just hope that ... 'fully integrated'
>means alpha T9 plus VCP. 
>Having lost several design-ins to Texas already, any hick-ups
>could be a real catastrophy for INMOS.

'fully integrated' does mean T9000 + VCP.

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. 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.

I will reiterate Roger Shepherds statement:-

>>> Recent progress on the T9000 has been good - a trade paper (Electronics
>>> Times?) reported CORRECTLY that the T9000 alpha silicon has now come
>>> out of fabrication and is being tested.  The first fully integrated T9000
>>> device should enter fab shortly.

regards,

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