HDTenEightyP/NetNews huggingface dataset:
From: rob@pact.nl (Rob Kurver)
Subject: Re: Dynamic memory (was: Re: Recursion in occam)
Organization: PACT, Delft, The Netherlands
Date: Mon, 23 Nov 1992 17:45:34 GMT

In <By1FGL.CKF@wizzy.com> andyr@wizzy.com (Andy Rabagliati) writes
about Occam and dynamic memory:

>Occam was designed as a parallel programming language, with concurrency
>implemented inter- and intra-processor.

>For a transputer way out on a limb somewhere, running out of memory
>resource is fatal.

Indeed.  So _programs_ should make sure they don't run out of memory.

Is this best accomplished by removing support for heap-based dynamic
memory from the language?  Or should you provide both static and
dynamic memory allocation, and tell people about the pros and cons
of each?

Why do you think it is impossible to run out of memory with static
memory allocation?  Don't fixed-size arrays fill up?  Don't you
actually fill up one of the fixed-size arrays quicker than one of
the dynamic-size arrays?

Statically allocating the available memory does not solve the
out-of-memory problem, but actually makes it worse!

Rob

--
     PACT                   Rob Kurver
    Foulkeslaan 87         rob@pact.nl
   2625 RB Delft     ph: +31 15 616864 
  The Netherlands   fax: +31 15 610032
From: wgd@ukc.ac.uk (W.G.Day)
Newsgroups: comp.sys.transputer
Subject: Re: IS Occam3 recursive?
Date: 19 Nov 92 13:56:05 GMT
Reply-To: wgd@ukc.ac.uk (Warren Day)
Organization: Computing Lab, University of Kent at Canterbury, UK.

In article <rob.722034771@dutncp8> rob@pact.nl (Rob Kurver) writes:
>I'm afraid you've lost me:  why do you think parallelism prevents
>recursion, pointers, dynamic memory and (especially) data structures?
>Parallelism may complicate matters, but it doesn't actually prevent any
>of these things.

As Roger Shepherd said, the mixture of the two, colours performance issues.

>Not necessarily.  A smart enough compiler system may well be able to
>support recursion at a small price if used, but without any overhead if

Why should there have to be a price.

>not used.  This can be implemented by a smart linker, which uses a call
                                         slow

>I don't believe it would be wise for Inmos or any other transputer
>compiler vendor to have parallel and sequential versions of their tools.

What I was suggesting was a sequential language (not that I want to wait
longer for occam 3, but).  This language looks like occam 3 and has a similar
foundation, but has no parallelism, instead it has recursion and pointers and
things.  However, I suspect that "recursion & pointers" and "similar
foundation" are logically incompatible.

>Cheers. - Rob

Warren
Newsgroups: comp.sys.transputer
From: rob@pact.nl (Rob Kurver)
Subject: Re: IS Occam3 recursive?
Organization: PACT, Delft, The Netherlands
Date: Tue, 17 Nov 1992 21:12:51 GMT

In <2292@eagle.ukc.ac.uk> wgd@ukc.ac.uk (Warren Day) writes:

>I would very much like such a language that has all the things that
>parallelism prevents: recursion, pointers, dynamic memory and data
>structures.

I'm afraid you've lost me:  why do you think parallelism prevents
recursion, pointers, dynamic memory and (especially) data structures?
Parallelism may complicate matters, but it doesn't actually prevent any
of these things.

>and there appears to be quite an argument along the lines of Michael's "why
>don't you have it and just not use it when you don't need it", which as
>Roger Shepherd said, means having two compilations approachs (if I understand
>correctly).

Not necessarily.  A smart enough compiler system may well be able to
support recursion at a small price if used, but without any overhead if
not used.  This can be implemented by a smart linker, which uses a call
graph to locate recursion and inserts stack allocation and expansion
code where necessary.  If no recursion is used, no stack expansion code
is introduced.

>             Perhaps Inmos have a market for a family of occam languages,
>occam.par and occam.seq.

I don't believe it would be wise for Inmos or any other transputer
compiler vendor to have parallel and sequential versions of their tools.
It may make sense to provide compiler options to allow stack stacking
and expansion to be tuned, in the absence of aforementioned smart
linker.

The CSP paradigm as supported by Occam and PACT Parallel C is a very
powerful one, and is especially interesting with the support provided
by the transputer.  It is up to the implementation to avoid unnecessary
overhead.

Cheers. - 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: podgorny@npac.syr.edu (Marek Podgorny)
Subject: Re: Transp. for Neural Nets etc.
Organization: Syracuse University NPAC/SCCS
Date: Fri, 13 Nov 92 16:23:59 EST

In article <1992Nov12.094923.28263@edb.tih.no>, christia@colargol (Segmentation fault (core dumped)) writes:
>Hi,
>
>[.....]  
>
>For a transputer system consisting of a motherboard, a T800 w. 2MBdram, and
>a C dev.kit I expect to pay aprx. $3000 - am I beeing ripped off?
>
>Thanx in advance.
>
>Christian Hilmersen 
>christia@edb.tih.no
>Norway

3 years ago, I paid for 4 such systems, albiet with 4 MB RAM each,
approx. 12,000 DM, occam + afserver included .  In February '91, Parsytec 
charged DM 2,700 for your configuration, and DM 2,200 for 3L C compiler. 

Marek Podgorny, NPAC, Syracuse University 
Newsgroups: comp.sys.transputer
From: eugene@wilbur.nas.nasa.gov (Eugene N. Miya)
Subject: Re: Recursion in occam
Organization: NAS, NASA Ames Research Center, Moffett Field, CA
Date: Mon, 23 Nov 92 21:32:35 GMT

In article <By1FGL.CKF@wizzy.com> andyr@wizzy.com (Andy Rabagliati) writes:
>If recursion can be guaranteed not to exceed a fixed memory resource,
>there seems to be no reason why it could not be added to the language.

I thought these arguments were left behind in the 60s.
Same argument was used for the design of NASA's HAL/S language.

--eugene miya, NASA Ames Research Center, eugene@orville.nas.nasa.gov
  Resident Cynic, Rock of Ages Home for Retired Hackers
  {uunet,mailrus,other gateways}!ames!eugene
Second Favorite email message: Returned mail: Cannot send message for 3 days
A Ref: Mathematics and Plausible Reasoning, vol. 1, G. Polya
From: harv@cis.ksu.edu (Harvard Townsend)
Newsgroups: comp.sys.transputer
Subject: Phone number Computer Systems Architecture
Date: 20 Nov 1992 20:09:31 GMT
Organization: Kansas State University, Dept. of Computing and Information Sciences
Distribution: world
NNTP-Posting-Host: depot.cis.ksu.edu

One of our faculty needs to contact a company called Computer Systems
Architecture in Utah. I'd appreciate an address and/or phone number.
I also need to contact INMOS as well, and heard they have an office in
Utah. Thanks for any help.
-- 
Harvard Townsend, Kansas State University Dept. of CIS
Internet: harv@cis.ksu.edu    UUCP: rutgers!depot!harv
From: dbc@ecs.soton.ac.uk (Bryan Carpenter)
Newsgroups: comp.sys.transputer
Subject: Re: Why Occam3 probably won't be recursive (was: IS Occam3 recursive?)
Keywords: Occam3 recursive, no
Date: 18 Nov 92 11:37:31 GMT

In <2225@eagle.ukc.ac.uk> wgd@ukc.ac.uk (W.G.Day) writes:

>...

>As the adding of recursion would prevent the compile-time-only memory
>allocation from being performed (occam programs should never run out of
>memory at runtime); I suspect not.

>However, having recently implemented the Towers of Hanoi on a processor farm
>and quicksort in occam (Tony Hoare's sort algorithm on C.S.P. hardware, hmm),
>I found the building of my own stack to hold the details of the recursing on
>to be the quite literally the easist part of the whole designing and writing
>process, and it's not something I've had to do before.  Doing it all yourself
>means you can build a queue instead of a stack and do things breadth-first if
>you wish.

Personally, I wouldn't object to building my own stack, if I just
had `malloc' to do it with.  Building my own `malloc' I object to
more strongly.

>Warren

Bryan
From: wayne@stan.xx.swin.oz.au (Wayne Cosshall)
Newsgroups: comp.sys.transputer
Subject: Problem with 3L C (REPOST)
Keywords: 3lc, transputer, software
Date: 23 Nov 92 05:55:48 GMT
Organization: Comp. Centre, Swinburne University of Tech., Melbourne, Australia


Sorry if you have already seem this but am trying a different source machine
due to possible posting problems with past version.

I have an interesting (to me) problem using the 3L C compiler.
I have an application consisting of twotasks running on the same transputer.
Both have file system access so are connected to a filemux task and thence
to the server through filter.
The problem I have is that only one of the two tasks actually gets any 
command line parameters given when the app is run.  The task that gets them
varies each time the program is run (YES I AM SURE OF THIS).

Now my question is is this normal for 3LC?  If so I can rewrite the app
to handle it.  Is it possible to control which task gets the command line?
What is going on?

If you respond to this can you let me know if you saw any earlier posts
by me on this.  If not, then I can go beat up the system programmer on the
machine I was using then.

Wayne J. Cosshall
Dept. of Computer Science
Swinburne University of Technology
Australia
wayne@saturn.cs.swin.oz.au


Newsgroups: comp.sys.transputer
From: andyr@wizzy.com (Andy Rabagliati)
Subject: Re: Recursion in occam
Organization: W. Z. I.
Date: Fri, 20 Nov 1992 23:19:32 GMT

Occam was designed as a parallel programming language, with concurrency
implemented inter- and intra-processor.

For a transputer way out on a limb somewhere, running out of memory
resource is fatal.

In most C environments, with a disk nearby, this is not a fatal
condition. Indeed, on a virtual memory machine, the application may not
even notice unless it was watching the clock.

If recursion can be guaranteed not to exceed a fixed memory resource,
there seems to be no reason why it could not be added to the language.

Guarantees up until now have not been forthcoming.

A simple system like tail-recursion can be implemented in a loop. To
put restrictions like "only use recursion when tail-recursing" or
"ping-disk < 10msec" would be a sad day for the occam-as-a-language
aficandos.

Hmm .. let me see - you seem to have enough memory THIS time - still
muddies the language waters but may be a compromise.

Cheers,     Andy.
-- 
andyr@wizzy.com  Andy Rabagliati, RR1 Box 33, Wyalusing, PA 18853 (717)746-7780
Newsgroups: comp.sys.transputer
From: rob@icarus.inmos.co.uk (Robin Pickering)
Subject: Re: Recursion in occam
Reply-To: rob@inmos.co.uk (Robin Pickering)
Organization: INMOS Limited, Bristol, UK
Date: Fri, 20 Nov 1992 10:26:03 GMT

In article <rob.722177288@dutncp8> rob@pact.nl (Rob Kurver) writes:
>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.
>
...
>
>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 system you describe does not "remove stack overflow", it simply makes
it impossible for the programmer to deduce the circumstances under which
a stack overflow will occur.

I can just see it now, an airliner on final approach, pilot hits the
undercarriage lever:

"Please wait, stack extension in progress"
....
"Stack extension failed (memory fragmented)"
"Error flag set (please re-boot)"

Get real, OCCAM was designed for programs where it was fairly important
to the programmer to be able to predict how the end system would behave.
Don't ask for OCCAM to have features introduced which break this critical
functionality.

If you want want quicker development cycles and don't mind indeterminate 
behaviour of your system at run-time, fine use C with these kinds of
extensions. Nothing wrong with that, for a certain class of applications
this is a perfectly acceptable programming environment (I use it a lot).
However please don't use such a system to develop software for any 
airliner that I might travel on! (or any other kind of system where failure
is anything other than a moderate inconvenience).


--
   Rob.
From: michael@uk.ac.oxford.robots (& Stevens)
Newsgroups: comp.sys.transputer
Subject: Re: IS Occam3 recursive?
Date: 16 Nov 92 18:55:58 GMT
Organization: Dept. Engineering Science, Oxford University, UK
In-reply-to: rob@pact.nl's message of 13 Nov 92 14:01:57 GMT

Now the arguments about recursion and OCCAM have been going a while I
though I would make a quick summary.

FOR recursion:
	1. Recursion is mathematically elegent. Serious software
engineering requires it.
	2. Code generation isn't hard. Handle the stack extension is possible.
If it can be done for C, you can do it for OCCAM.
	3. You don't need to use it. If you want to be able to
predetermine memory usage at compile time don't recurese.
	4. Why single out memory as the single resource that should be
predetermined at compile time. Time is another resource that runs out,
and so does disk space.

AGAINST recursion:
	1. OCCAM 2 doesn't do it.
	2. Its not implemented in OCCAM 2.
	3. Thats all I can think of, but I am sure it has something to
do with OCCAM 2.

Personally I think the arguments against have it :-)

Ok enough humour, how about the even tricker issue of dynamic memory
allocation. Does OCCAM 3 need it as part of the language? Should OCCAM
3 have type safe pointers? Or should we be content with INT32 and
library procedures to allocate memory?

Would all this overburned OCCAM and turn it into yet another hacked up
language like C?

Michael Stevens, Robotics Research Group,Dept of Engineering Science,Oxford,UK
INTERNET: michael@robots.oxford.ac.uk
--
Michael Stevens, Robotics Research Group,Dept of Engineering Science,Oxford,UK
INTERNET: michael@robots.oxford.ac.uk
From: R.Peel@ee.surrey.ac.uk (Roger Peel)
Newsgroups: comp.sys.transputer
Subject: Re: Dynamic Memory Allocation
Keywords: Occam3 recursive
Date: 20 Nov 92 17:50:20 GMT
Organization: University of Surrey, Guildford, Surrey, UK. GU2 5XH

Andy Newman (andy@research.canon.oz.au) wrote recently about his
involvement with a project that developed a Dynamic Memory Allocator.

I liked his account of the memory allocation procedure - and his honesty
about its non-adherence to the occam usage checking rules!

I have one comment to add.  The parallel process in the middle (the
allocator process) can very easily become the performance bottleneck of
the whole of the rest of the system, since it queues up requests and
responds to them serially.

Apart from the problem of distributing permissions to access memory blocks
of varying sizes, one might consider implementing such an allocator with a
little extra buffering.  This would have the effect of eagerly outputting
(in parallel) a permission token to each process that it serves.  Only
when a process accepts its token does the allocator reschedule and send it
another one.  Returned tokens are processed along a different set of
channels which are quite separate from the first set.  Think of the
allocator and the client processes as each being separated in both
directions by small FIFOs, and notice the reduced latency that this
provides.  Obviously, more tokens will be in transit at any time, and the
scheme will use its memory pool less effectively - but the benefit could
be that the system runs rather faster.

A similar benefit could be gained when implementing the TCP/IP
communications protocol, if one has also decided to use the 'mbuf' memory
allocation scheme suggested in its specification.  In this case, and under
heavy network loads, the allocator will be very busy and the overhead
could be quite noticeable.  Of course, this shared memory model might not
be the best choice these days, anyway!


Roger M.A. Peel
Department of Electronic and     Phone : +44 483 509284   (0483 from UK)
      Electrical Engineering       Fax : +44 483 34139
University of Surrey             Telex : 859331
Guildford                        JANET : R.Peel@uk.ac.surrey.ee
Surrey  GU2 5XH                   UUCP : ...mcsun!ukc!ee.surrey.ac.uk!R.Peel
United Kingdom


-- 
Roger Peel
Newsgroups: comp.sys.transputer
From: rob@pact.nl (Rob Kurver)
Subject: Re: GNU cc port to tranputer
Organization: PACT, Delft, The Netherlands
Date: Fri, 20 Nov 1992 12:00:46 GMT

In <Bxz6ps.37y@da_vinci.it.uswc.uswest.com> scollins@lookout.it.uswc.uswest.com (Steven Collins) writes:

>Is anyone working on porting the GNU cc compiler 
>to the transputer? 

This has been talked about since 1985 or so.  I've never seen any
results, nor heard specific reasons why it wasn't done or didn't
succeed.

>I have looked into porting it but GNU's cc
>compiler expects a multi-register CPU and since
>the transputer is stack based,  there
>could be some sticky problems to overcome.

>Even if a port is done,  performance of the
>output code may suffer since it will be hard to
>use the same optimization routines. 

From what I know of GCC (a bit) and of transputer code generation (a lot),
I'd say they don't match very well.  I'd be very interested in seeing
anybody map the GNU RTL onto the transputer stack.  Very interested...

>I'm still investigating the effort involved.

>Any comments?

Please post a summary of your findings.  I'd like to know if anybody
every actually attempt a port, and how things worked out for them.

>||  Steve Collins          ||  INTERNET: scollins@uswest.com      ||

Cheers. - Rob

--
     PACT                   Rob Kurver
    Foulkeslaan 87         rob@pact.nl
   2625 RB Delft     ph: +31 15 616864 
  The Netherlands   fax: +31 15 610032
From: jnv@cl.cam.ac.uk (Neil Viljoen)
Newsgroups: comp.sys.transputer
Subject: B004 Compatible cards forsale
Date: 23 Nov 92 12:16:46 GMT
Reply-To: jnv@cl.cam.ac.uk
Organization: Cambridge Hardware Verification Group

----
I have two B004 compatible cards available.
Specs: T800 20 Mhz
       2Mb (expandable by simms to 8)
Offers?

------------------------------------------------------------------------------
Neil Viljoen			|  Tel: +44-223-334688
Univ. of Cambridge		|  Fax: +44-223-334678
Computer Laboratory		|  
Pembroke Street			|  Email: jnv@cl.cam.ac.uk
Cambridge CB2 3QG		|
England				|
From: djp@ecs.soton.ac.uk (David Pritchard)
Newsgroups: comp.sys.transputer
Subject: Re: IS Occam3 recursive?
Date: 23 Nov 92 11:40:47 GMT
Reply-To: djp@ecs.soton.ac.uk
Distribution: world
Organization: SNARC

In article 92Nov16185558@lucrece.uk.ac.oxford, michael@uk.ac.oxford.robots (& Stevens)
 writes:
>Now the arguments about recursion and OCCAM have been going a while I
>though I would make a quick summary.
>
>FOR recursion:
>	1. Recursion is mathematically elegent. Serious software
>engineering requires it.
Rubbish.  It is true that mathematical elegance is `nice', but 
serious engineering is not about producing nice programs for display
at the Tate, but robust programs which do what they are designed to do
when they are asked to do it.  Every time.  Even when operated by
morons.  

>	2. Code generation isn't hard. Handle the stack extension is possible.
>If it can be done for C, you can do it for OCCAM.

Rubbish.  C has one stack, when it fills you are stuck with no way out
anyway.  OCCAM would need p stacks - where p is the number of processes
(which changes dynamically).  When one runs out, you might have been 
better off making that one bigger and the others smaller - but it is
too late.

>	3. You don't need to use it. If you want to be able to
>predetermine memory usage at compile time don't recurese.
This seems OK, but there is probably something wrong with it.

>	4. Why single out memory as the single resource that should be
>predetermined at compile time. Time is another resource that runs out,
>and so does disk space.
>
Because memory CAN be predetermined, the others cannot.  Computing 
time is data dependent and would probably involve solving the halting
problem.  Disk space ditto.


>AGAINST recursion:
>	1. OCCAM 2 doesn't do it.
Neither does FORTRAN.

>	2. Its not implemented in OCCAM 2.
See Geoff Barrett for the dirty trick which makes it look as though
it is.

>	3. Thats all I can think of, but I am sure it has something to
>do with OCCAM 2.
OCCAM 1 is all that is NEEDED.

--
Dr David J. Pritchard		
Electronics and Computer Science	tel	(+44 703) 592722
University of Southampton		fax	(+44 703) 593045
Southampton SO9 5NH			email	djp@uk.ac.soton.ecs (UK)
United Kingdom					djp@ecs.soton.ac.uk (World)
From: nht@cs.bham.ac.uk (Neville H Thomas)
Newsgroups: comp.sys.transputer
Subject: Re: IS Occam3 recursive?
Date: 17 Nov 92 11:16:16 GMT
Organization: School of Computer Science, University of Birmingham, UK

In article <MICHAEL.92Nov16185558@lucrece.uk.ac.oxford> michael@uk.ac.oxford.robots (& Stevens) writes:
>Now the arguments about recursion and OCCAM have been going a while I
>though I would make a quick summary.
>
>FOR recursion:
>	1. Recursion is mathematically elegent. Serious software
>engineering requires it.
>	2. Code generation isn't hard. Handle the stack extension is possible.
>If it can be done for C, you can do it for OCCAM.
>	3. You don't need to use it. If you want to be able to
>predetermine memory usage at compile time don't recurese.
>	4. Why single out memory as the single resource that should be
>predetermined at compile time. Time is another resource that runs out,
>and so does disk space.
>
>AGAINST recursion:
>	1. OCCAM 2 doesn't do it.
>	2. Its not implemented in OCCAM 2.
>	3. Thats all I can think of, but I am sure it has something to
>do with OCCAM 2.
>
>Personally I think the arguments against have it :-)
>
>Ok enough humour, how about the even tricker issue of dynamic memory
>allocation. Does OCCAM 3 need it as part of the language? Should OCCAM
>3 have type safe pointers? Or should we be content with INT32 and
>library procedures to allocate memory?
>
>Would all this overburned OCCAM and turn it into yet another hacked up
>language like C?
>

Three years ago I wrote a large program in Occam2.

After writing some stack based utilities using arrays in Occam to
allow simulated recursion. This took time to develop.

Nowadays I use Inmos Parallel C which is a far more usable language.



-- 
Email: N.H.Thomas@cs.bham.ac.uk     G7ABW
Work:   Fax: +44 (0)21 414 4281     Tel: +44 (0)21 414 3736
Home:   Fax: +44 (0)21 454          Tel: +44 (0)21 454 5729
Mobile: +44 (0)891 
Newsgroups: comp.sys.transputer
From: rob@pact.nl (Rob Kurver)
Subject: Re: IS Occam3 recursive?
Organization: PACT, Delft, The Netherlands
Date: Mon, 23 Nov 1992 15:13:18 GMT

In <2306@eagle.ukc.ac.uk> wgd@ukc.ac.uk (W.G.Day) writes:

>>Not necessarily.  A smart enough compiler system may well be able to
>>support recursion at a small price if used, but without any overhead if

>Why should there have to be a price.

Few things in life are free.

>>not used.  This can be implemented by a smart linker, which uses a call
>                                         slow

I don't think building a call-graph during linking gives a noticeable
performance difference.  The time required is certainly negligible
compared to the time needed for file I/O.  If you have data that shows
otherwise, please post it.

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