Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!ncar!boulder!unicads!les From: les@unicads.UUCP (Les Milash) Newsgroups: comp.sys.transputer Subject: Re: Dynamically creating arrays of processes Keywords: Non VAL limits in PAR FORs Message-ID: <340@unicads.UUCP> Date: 27 Mar 89 17:12:24 GMT References: <2380@buengc.BU.EDU> <4526@cloud9.Stratus.COM> Reply-To: les@unicads.UUCP (Les Milash) Organization: Unicad Boulder, CO Lines: 96 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.