dpm@buengc.BU.EDU (Daniel P. Martin) (03/25/89)
I am considering an application in Occam that naturally lends itself to implementation as a square array of processes with nearest neighbor channel interconnection. The only problem is Occam's restriction of the PAR FOR construct to limits known at compile time. My application would have limits that vary during execution. While I can think of ways around this limitation, I would rather work within the Occam process model. A related issue is multiplexing dynamically allocated channels over a single link. Has anyone examined these issues? Should I be considering using another language?
cme@cloud9.Stratus.COM (Carl Ellison) (03/25/89)
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)
cs395t54@cs.utexas.edu (Pow Hwee Tan) (03/26/89)
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.
phles@unicads.UUCP (Les Milash) (03/28/89)
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.
les@unicads.UUCP (Les Milash) (03/28/89)
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
WHITCOMB%KOBOT@VENUS.YCC.YALE.EDU ("whitcomb%kobot.decnet@venus.ycc.yale.edu") (03/28/89)
>From: KOBOT::WHITCOMB "whitcomb%kobot.decnet@venus.ycc.yale.edu" 25-MAR-1989 15:49
To: VENUS::IN%"buengc!dpm@bu-cs.bu.EDU",WHITCOMB
Subj: RE: Dynamically creating arrays of processes
Greetings:
Recall that there is nothing in the occam language definition which
denies the possibility of dynamic space allocation or recursion. Likewise
with the transputer cpu. The inmos implementation of this language has
these restrictions; thus it is in *implementation* limitation rather than a
language limitation. This is a win for safety (correctness) and speed,
at the cost of functionality.
Dynamic space allocation may be achieved within the occam model by
explicitly creating and managing a heap for use by parallel
processes within the scope of its definition. The use of such a heap will,
unfortunately, often violate the occam access restrictions on arrays and
thus you will have to switch off some of the compiler checks.
Dynamic code loading, however, is not part of the occam definition. It
may be achieved in the inmos implementation of occam by using a predefined
library procedure "KERNEL.RUN". This is defined in section 11.3 of the
Transputer Development System manual (1988, Prentice Hall, ISBN 0-13-928995-X.)
I hope this helps. The Best,
Louis L. Whitcomb