🚀 go-pugleaf

I haven't looked at occam in a couple of years but back then there was
no way to do ANYTHING dynamic (even allocate storage), so I called
INMOS and asked about it.  My inquiry took me all the way to the
president of INMOS -- and everywhere the answer was the same --

nothing dynamic for occam -- nothing dynamic for the chip.

So, I begged for info with which to write my own assembler (and, from there,
my own compiler with lots of dynamic stuff), but before I could get
INMOS to release such information, the project was cancelled and I went
into observer mode.  (all at a previous company)

Has any of this changed?


--Carl Ellison                      UUCP::  cme@cloud9.Stratus.COM
SNail:: Stratus Computer; 55 Fairbanks Blvd.; Marlborough MA 01752
Disclaimer::  (of course)

Although Occam does not allow dynamic creating of processes, there
is a way of getting around it, which is mentioned in Alan Burn's
book on Occam programming. 

This method requires you to know the maximum number of processes you
want to create.  Suppose the max number of processes is max.p and
the variable number of processes you want to create is amount.p then
one can write this in the program:

  PAR i = 0 FOR max.p
    IF 
      i >= amount.p  -- extra process
        SKIP  -- skip them
      TRUE
        SEQ
          -- insert what you want to do here.

Note that this method still requires static binding on the number
of processes you can create at compile time, and you will
waste some amount of CPU time because of the extra processes
created and SKIP.

ph

In article <4526@cloud9.Stratus.COM> cme@cloud9.Stratus.COM (Carl Ellison) writes:
>
>I haven't looked at occam in a couple of years but back then there was
>no way to do ANYTHING dynamic (even allocate storage), so I called
>INMOS and asked about it.  My inquiry took me all the way to the
>president of INMOS -- and everywhere the answer was the same --
>
>nothing dynamic for occam -- nothing dynamic for the chip.
>
>So, I begged for info with which to write my own assembler (and, from there,
>my own compiler with lots of dynamic stuff), but before I could get
>INMOS to release such information, the project was cancelled and I went
>into observer mode.  (all at a previous company)
>
>Has any of this changed?
>
>
>--Carl Ellison                      UUCP::  cme@cloud9.Stratus.COM
>SNail:: Stratus Computer; 55 Fairbanks Blvd.; Marlborough MA 01752
>Disclaimer::  (of course)

Newsgroups: comp.sys.transputer
Subject: Re: Dynamically creating arrays of processes
Summary: 
Expires: 
References: <2380@buengc.BU.EDU> <4526@cloud9.Stratus.COM>
Sender: 
Reply-To: les@sirius.UUCP (Les Milash)
Followup-To: 
Distribution: 
Organization: Unicad  Boulder, CO
Keywords: Non VAL limits in PAR FORs

advAPPOLOGIESance if i mess this all up, it's my first posting...

In article Carl Ellison writes:
>
>nothing dynamic for occam -- nothing dynamic for the chip.
                                              ^^^ ^^^ ^^^^*
                     ^^^^^ prob still true, cause the occam compiler
wants to be able to compute the stack usage of each procedure, and so
the size of the activation record has to be known at compile time, and
if you're a procedure and you launch a bunch of processes you need to
give them enough memory to run.  this is also why daRned occam programs
can't be recursive--cause whether they use a finite amount of memory is
program/data-dependent (although CARHoare is so smart he could probably
figure a way to prove at compile time that a recursive procedure does'nt 
run away, and if he can't prove it why should you expect it)
and i bet the trick about creating a huge number of processes
at compile time and then at run-time having each of them decide whether
or not they should just SKIP costs more than just time, it costs Memory,
in your local stack frame, and perhaps alot, since namely each of them 
needs to have enough memory for the worst-case (the case where the sub-
process won't skip.

and memory costs bucks, at least for me; if i have to go past 1Mbyte then
i guess i gotta get a bunch of those little resistors and some big
drivers and learn about electricity!  yuck!  and those chips! $$!

PLEASE NOTE! all of the above is just a rumour; i figured it all out (or
maybe got it radically wrong) by just thinking about how it's gotta work.  my
original goal was just to see if i had a legitimate gripe about the lack
of recursion, but now is see that it's just a hard problem.

* never was true; the chip is really nice.  I've bought Kirk Bailey's
(Logical Systems Inc.) C compiler and talked to him about how you do things
there, it'll let you create dynamic arrays of processes (thru a library).  
but YOU have to get it (the new process) some stack of its very onw, 
since you expect to mess around above the top of your own.

I've figured out a way around this (in C and potentially OCCAM) -- call
if you're interested.  I'm gonna try to retrofit it into LSI-C (sounds like
fun :-) )

By the way, i'm just a cocky young whippersnapper, so you should take this
all with a grain of salt.  But i've build hot h/w & cool s/w so i'm not
completely out-to-lunch.

Here's my best quote for The Age of Parallel Computing: "everyone (all running 
processes) needs a top-of-stack, and it's a scarce resource."  between that 
and the fact that lots of C runtime memory-management libraries let you 
fragment the heck out of your space to the point where you've got piles of 
memory but none usable (hope SDI ain't built in C (or at all for that matter)) 
makes me real enamored with lisp-style memory management (not the GC, but the
fact that if i free something it's good enough for re-use.

>So, I begged for info with which to write my own assembler (and, from there,
>my own compiler with lots of dynamic stuff), but...  Has any of this changed?
                                                                      ^^^^^^^
yes, INMOS publishes "The transputer instruction set--a compiler writer's
guide" which is real nice, even has the definitions of the instructions in
some funny CSP-ish RTL, so you could build your own in 74LS.  They don't just
tell you the instructions, they tell you how to compile for the chip.
I got it free, just for eating sweet-rolls and drinking coffee while some 
pre-computed ray-traced molecules splashed around in a vat of mercury
"realtime".  that T8 can really blit.

in any case, OCCAM or C, my bet is that designing programs that use
a rectangular mesh of processes is a good idea.  i realize that i'm
prob not the first to notice this, but i've never heard anyone say it:
1.	count the number of links on a T8
2.	examine the INMOS logo very closely--what does that remind you of?
i'd say those who like 2d arrays of processes with just a few K of stack &
state might be able to buy some very suitable hardware one of these days.
maybe they'll hire sir clive...

  T--T   Les Milash (w)303-443-6961 graphix s/w slave, Unicad Inc.
 /| /|   (h)303-444-8552348 Arapahoe #17 Boulder CO USA 80302
T-+T |   my opinions are so different from those of my employer :-(
| T+-T   that i often look for a different employer :-)
|/ |/    and that's what these are.
T--T