Newsgroups: comp.sys.transputer
From: A.Kruse@nikhef.nl (Andres Kruse (NIKHEF),1c/137,2909)
Subject: Re: OCCAM3 (was :- Revision of occam 2 Referenc
Organization: NIKHEF - Amsterdam
Date: 6 Aug 1994 11:43:56 GMT
Message-ID: <31vt1s$bf6@dscomsa.desy.de>

In article Mwt@wizzy.com, andyr@wizzy.com (Andy Rabagliati) writes:
> >peter@bustard.inmos.co.uk (Peter Hassall) writes:
 
> >> INMOS is considering a revision of the occam 2 Reference Manual in the
> >> near future and would appreciate any comments on the current edition.

> Andres Kruse (NIKHEF),1c/137,2909 <A.Kruse@nikhef.nl> wrote:

> >What about a questionaire to OCCAM2 users about what they would like
> >to have implemented in new OCCAM versions ? 

> This has little relevance to documenting OCCAM2.

True.


> That said,

> >I guess many people will agree that:

> >- structures are a MUST !

> But they are already in OCCAM3.

Oops. I didn't know that OCCAM3 is being worked on already.. 
Is it available yet ?

Thanks for the hint.

> >- pointers should be there as well.
> >- 'PAR FROM something FOR something' where 'something' are variables
> >  which can change at run-time.

> These are not in OCCAM2 for a reason. Not being familiar with progress
> on OCCAM3, I do not know wether they are in OCCAM3.

> However, the reasons that they are not in OCCAM2 could keep them out of
> OCCAM3 too.

> Those reasons are :-

> * Inability to write a Usage Checker

> * Indeterminate memory requirements.

Yes. Sounds like good reasons, but as a programmer you just have to be
very carefull when using pointers then. Same with using pointers in
other languages (C, Pascal, Fortran).

> >- RETURN from a PROC or FUNCTION... (dunno how to handle RETURNs in
> >  a PAR.. maybe the compiler could restrict the use of RETURNs to
> >  PROCs which don't have PARs..)

> I am not sure what you mean here. If you mean RETURN from the middle of
> a function, then there is no functionality added to the language, just
> confusion.

Well.. It's simply inconvenient if you find out in the middle of your
FUNCTION that you should not continue. I always declare then a BOOL everything.ok
and test on it.. but that's not really nice. But maybe there is a better
way ?

[snip] (tm)

> You can download the current spec of OCCAM3 from unix.hensa.ac.uk.
> As you can tell, I have not.

Will do. Thanks.

> If you want to write in C, there is always the C compiler. More effort
> is put into the Inmos C compiler than the OCCAM compiler, so you are
> still getting state-of-the-art.

Hm... Haven't looked into that.. From what I hear of people using C on
transputers (may be a different compiler) it is much more inconvenient 
to create parallel processes and synchronise them. In OCCAM parallelism
is pretty well expressed in the code.
Most people in the high-energy physics experiment I work with are using
OCCAM2. We have about ~500 transputers used for real-time data acquisition
connected to a huge network. About 20 people or so are developing transputer 
programs here..

Only speaking for myself: Apart from the few features I mentioned in my
previous post which I think are missing in OCCAM2 I'm quite happy with 
transputers and OCCAM.


> Cheers,     Andy.

> --
> The birds have vanished into the sky,	     Andy Rabagliati  andyr@wizzy.com 
>    and now the last cloud drains away.			    W.Z.I. Consulting
>       We sit together, the mountain and me,		      +1.719.635.6099
>          until only the mountain remains.   -- Li Po (701-762)

Cheers,

      Andres (A.Kruse@nikhef.nl)



