🚀 go-pugleaf

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.