oskard%kanga@cs.umass.edu (DAVID OSKARD) (08/02/89)
I originally posted this through Internet news and apparently many of you didn't get it, so my apologies to those of you seeing this twice. If you had the chance to do it all over again, would you buy Occam or one of the third party compilers for the Transputer? To me it seems that the lack of support for data structures in Occam is in itself reason enough to consider other possibilities. Is this really as big a deal as it seems? How have you gotten around Occam's limitations? We have also heard that there are plans to support calls to C functions (and other languages?) from within Occam. Does this functionality exist yet? We are in the process of purchasing a transputer system to use as a low-level controller for a robot hand using a Sun 4 as a host. Any opinions out there? David Oskard University of Massachusetts oskard@cs.umass.edu
jps@cat.cmu.edu (James Salsman) (08/02/89)
In article <8908011650.AA12679@kanga.cs.umass.edu.edu> oskard%kanga@cs.umass.edu (DAVID OSKARD) writes: > If you had the chance to do it all over again, would you buy > Occam or one of the third party compilers for the Transputer? Occam is far superior for multiprocessing than any serial language (such as C) and it's model is much more safe and effective than Ada's. The problem is that the C-weenies of the world have not yet aquired the brain capacity to understand the beauty and functionality of Occam -- yet. The only thing I would change is to allow value functions to be recursive and specify that tail recursion is properly dealt with (as in Scheme.) > To me it seems that the lack of support for data structures in Occam > is in itself reason enough to consider other possibilities. Is this > really as big a deal as it seems? How have you gotten around Occam's > limitations? Hey! How about "Procedural Abstraction?" What a concept... The lack of dynamic memory allocation in Occam is easily overcome by allocating a large array, and using procedures for allocation and freeing of individual elements. If you do it right, and know how to use the retyping system, you can create a generalized heap storage system, where the same memory is used to store many types of data. The macho way to do it is to create a tagged protocol channel coprocess that allocates memory and handles access and (de)allocation functions. Then, you can place the process on whatever processor has the RAM (or the disk) for the data that you're storing. This is a cool programming technique, as well as a neat abstraction. :James Disclaimer: The University doesn't always agree with me. -- :James P. Salsman (jps@CAT.CMU.EDU) -- :James P. Salsman (jps@CAT.CMU.EDU)
stein@pixelpump.osc.edu (Rick 'Transputer' Stein) (08/02/89)
In article <5726@pt.cs.cmu.edu> jps@cat.cmu.edu (James Salsman) writes: >In article <8908011650.AA12679@kanga.cs.umass.edu.edu> oskard%kanga@cs.umass.edu (DAVID OSKARD) writes: >> If you had the chance to do it all over again, would you buy >> Occam or one of the third party compilers for the Transputer? > >Occam is far superior for multiprocessing than any serial >language (such as C) and it's model is much more safe and >effective than Ada's. The problem is that the C-weenies >of the world have not yet aquired the brain capacity to >understand the beauty and functionality of Occam -- yet. I have to take exception to this statement. I might write my concurrent programs in C, but that doesn't mean that I'm a "weenie." I have found C to be far more capable for creating data abstractions than occam. For my money, any form of computer simulation is dependent on 2 things: 1) Abstraction of the problem specification into structures which mimic their "real-world" behavior, and 2) The creation of operators for these strucutures. This programming style is more easily achieved with C, C++, or Ada, than with occam. Occam is indeed a highly secure language. As far as C goes, I would suggest that you not carry a gun unless you can shoot straight. I've blown several holes in feet during the creation of multicomputer software in C, but you overcome these "programming errors" by relying on module testing and the employment of a software engineering design methodology for multicomputers. I'm not sure I understand what is meant by your statement, "Occam...is more effective than Ada." I suppose in certain respects, like rendezvous, or concurrency control in tasking, yes I agree. But in other ways, like abstraction, data typing, data hiding, etc. occam don't quite cut the mustard. > >The only thing I would change is to allow value functions >to be recursive and specify that tail recursion is properly >dealt with (as in Scheme.) I agree with this. Recursion is a very useful thing, and I'm not the type to manage my own stacks of stuff (I'm generally too lazy or stupid for this). Unfortunately, inserting recursion into the occam langauge would require the incorporation of dynamic memory allocation. You need it to build call stack frames and the like. > >The macho way to do [dynamic memory allocation] is to create a >tagged protocol channel coprocess that allocates memory and >handles access and (de)allocation functions. Then, you can place the >process on whatever processor has the RAM (or the disk) for >the data that you're storing. This is a cool programming >technique, as well as a neat abstraction. Whatever turns you on. I just use malloc. >:James -=- Richard M. Stein (aka Rick 'Transputer' Stein) Concurrent Software Specialist @ The Ohio Supercomputer Center Trollius: The Official Multicomputer OS of the 1992 Olympic Games Internet: stein@pixelpump.osc.edu, Ma Bell Net: 614-292-4122
arc1@ukc.ac.uk (A.R.Curtis) (08/02/89)
In article <5726@pt.cs.cmu.edu> jps@cat.cmu.edu (James Salsman) writes: >In article <8908011650.AA12679@kanga.cs.umass.edu.edu> oskard%kanga@cs.umass.edu (DAVID OSKARD) writes: >> If you had the chance to do it all over again, would you buy >> Occam or one of the third party compilers for the Transputer? > I wouldn't buy transputers... >Occam is far superior for multiprocessing than any serial >language (such as C) and it's model is much more safe and >effective than Ada's. The problem is that the C-weenies >of the world have not yet aquired the brain capacity to >understand the beauty and functionality of Occam -- yet. > occam's model is far too simple. The reason the model is safer is that it has so little in it. I have acquired the brain capacity to understand occam, and I can see virtually no functionality. And as for beauty... >The only thing I would change is to allow value functions >to be recursive and specify that tail recursion is properly >dealt with (as in Scheme.) > occam has compile-time allocated memory. It deals solely with *real* memory, and none of this nice run-time virtual memory. >> To me it seems that the lack of support for data structures in Occam >> is in itself reason enough to consider other possibilities. Is this >> really as big a deal as it seems? How have you gotten around Occam's >> limitations? > >Hey! How about "Procedural Abstraction?" What a concept... What do you mean by "Procedural Abstraction"? Having procedures? I don't really think this is a great leap forward... > >The lack of dynamic memory allocation in Occam is easily >overcome by allocating a large array, and using procedures >for allocation and freeing of individual elements. If you >do it right, and know how to use the retyping system, you >can create a generalized heap storage system, where the same >memory is used to store many types of data. > Ok, so how do you provide a memory allocation server to handle completely arbitrary types? You can't, can you? But I can do this in C, can't I? Also, allocating a lump of memory yourself as the heap has nasty drawbacks. The size depends on how much memory is on the processor. Less memory, less space - how do you allocate according to memory availability? You can do it manually, but that stinks. It means that all of this lump has been removed from the available pool of memory. Why not let the system do the allocation for you? >The macho way to do it is to create a tagged protocol >channel coprocess that allocates memory and handles access >and (de)allocation functions. Then, you can place the >process on whatever processor has the RAM (or the disk) for >the data that you're storing. This is a cool programming >technique, as well as a neat abstraction. > Yes, but it can't work in the general case. You can't provide a server which will (de)allocate any arbitrary structure for you. You run up against the protocol problems of occam at high speed there, and the results are messy, because you can't specify arbitrary data types. >Disclaimer: The University doesn't always agree with me. And neither do I... Tony Curtis
bgr@long-grain.Rice.EDU (Robert G. Rhode) (08/03/89)
> >The only thing I would change is to allow value functions > >to be recursive and specify that tail recursion is properly > >dealt with (as in Scheme.) > I agree with this. Recursion is a very useful thing, and I'm not > the type to manage my own stacks of stuff (I'm generally too lazy or > stupid for this). Unfortunately, inserting recursion into the occam > langauge would require the incorporation of dynamic memory allocation. > You need it to build call stack frames and the like. I believe (and I'm sure I will be corrected if I am wrong :-) ) Scheme handles tail recursion by re-using the existing stack frame, thus not using any more memory than a single function call. I think I saw this in Dybvig's book. Robert Rhode | "Today's champion rhode@ricevm1.rice.edu | is tomorrow's crocodile shit." bgr@uncle-bens.rice.edu | Monty Python : Contractual Obligation Album
jps@cat.cmu.edu (James Salsman) (08/03/89)
In article <275@oscsuna.osc.edu> stein@pixelpump.UUCP (Rick 'Transputer' Stein) writes: > I have found C to be far more capable for creating data abstractions > than occam. For my money, any form of computer simulation is dependent > on 2 things: 1) Abstraction of the problem specification into structures > which mimic their "real-world" behavior, and 2) The creation of operators > for these strucutures. This programming style is more easily > achieved with C, C++, or Ada, than with occam. In Occam, abstraction is by processes. Operators, then, are messages sent (through channels) to the processes. This seems simple to me and fits well into your simulation model. Which dialect of C do you use for multiprogramming? :James -- :James P. Salsman (jps@CAT.CMU.EDU)
pcf@galadriel.bt.co.uk (Pete French) (08/03/89)
> effective than Ada's. The problem is that the C-weenies > of the world have not yet aquired the brain capacity to > understand the beauty and functionality of Occam -- yet. The "C-weenies" of this world are quite capable of understanding its beauty within the conbtext of the transputer. Certainly I would not want to try and write highly parallel code for a transputer network using a serial language. Thhe point you are missing is this - a language is not intrinsicly "good" or "bad" you can only use these terms relative to the situation in which you are using it. Try writing some UNIX systems programs in OCCAM and I'm sure that you'll be back to /bin/cc very quickly. Lack off dynamic memory allocation is a problem within Occam - its silly to say that it isnt. It prevents code being written to use varying amounts of memory on a system. The lack of structures is not a real problem since a structure doesnt really exist - it is compiled to be just a manipulation of bytes and words so why not program it thus ? For waht I am doing I find that Occam is a very good language, I am not sure that trying to start an argument over which parallel language is best is a good idea since it could easily turn into "You can do such-and-such in langauge X" to which a language X supporter can turn round and say "Why should I want to ?". -Pete French.
shafto@eos.UUCP (Michael Shafto) (08/03/89)
For those who are primarily interested in exploring the concepts of CSP (rather than producing blazingly fast programs on parallel hardware), I believe the Icon programming language is worth looking at. It's public domain, well supported, well documented, portable to many machines, written in C; it supports more than the usual complement of datatypes; it supports coroutines. It is very easy to implement (i.e., model) all CSP operators in Icon. (I will provide some illustrative code on request -- amateurish, but then it's so easy that amateurs can do it!) Since Icon is implemented in C, it's essentially a high-level C. C programmers should find it very easy to learn, and it lives very happily (though not exclusively) in Unix environments. It seems to me that Icon should be readily adaptable to real parallel hardware, but I'm not sure whether anyone has done it. Mike Refs -- The Icon Programming Language by Ralph & Madge Griswold, Prentice-Hall; The Implementation of the Icon Programming Language, same authors, Princeton University Press; multo tech reports available from the Icon Group, Department of Computer Science, The University of Arizona, Tucson, AZ 85721 USA
stein@pixelpump.osc.edu (Rick 'Transputer' Stein) (08/03/89)
In article <5739@pt.cs.cmu.edu> jps@cat.cmu.edu (James Salsman) writes: >In article <275@oscsuna.osc.edu> stein@pixelpump.UUCP (Rick 'Transputer' Stein) writes: > >> I have found C to be far more capable for creating data abstractions >> than occam. For my money, any form of computer simulation is dependent >> on 2 things: 1) Abstraction of the problem specification into structures >> which mimic their "real-world" behavior, and 2) The creation of operators >> for these strucutures. This programming style is more easily >> achieved with C, C++, or Ada, than with occam. > >In Occam, abstraction is by processes. Operators, then, are >messages sent (through channels) to the processes. This >seems simple to me and fits well into your simulation model. I agree. The whole notion of simulation and concurrency does cleanly abstract to processes and communication interfaces. > >Which dialect of C do you use for multiprogramming? Well, I don't know if the Unidot C compiler available with the Trollius OS is completely X3J11, but its a fair one. I insert Trollius calls into my software when message passing is needed or kernel services are required. All Trollius dependencies can be ifdef'd away if portability to sequential execution is a requirement. But the great thing about Trollius is the kernel congruency between "In the Box" (aka, Txxx) nodes, and the host node ("Out of the Box"). You can easily simulate and verify the logical concurrency of your model in a shared-memory with Trollius, and then simply, without changing a line of code, pump your software into a physically concurrent box of transputers. If you do your design correctly, the shared-memory model can be debugged with a standard (yucky) breakpoint debugger, and the Trollius state command. Its pretty clean. >:James -=- Richard M. Stein (aka Rick 'Transputer' Stein) Concurrent Software Specialist @ The Ohio Supercomputer Center Trollius: The Official Multicomputer OS of the 1992 Olympic Games Internet: stein@pixelpump.osc.edu, Ma Bell Net: 614-292-4122
jps@cat.cmu.edu (James Salsman) (08/04/89)
In article <1948@harrier.ukc.ac.uk> arc1@ukc.ac.uk (A.R.Curtis) writes: > occam has compile-time allocated memory. It deals solely with *real* > memory, and none of this nice run-time virtual memory. By "virtual memory" do you mean "allocatable heap storage" or "memory paged out to disk"? Occam can do both. A Transputer OS should provide a process for these functions. > [In reply to the idea of using process abstraction for an > "allocation server" -jps] > Ok, so how do you provide a memory allocation server to handle > completely arbitrary types? You can't, can you? But I can do this in > C, can't I? I can tell that you aren't an Occam programmer because you don't know about CHAN OF ANY and PORT OF ANY -- these protocols map everything back and forth into BYTEs. In C, malloc returns a char pointer, while in the more logical Occam, typelessness is declared as "anarchic protocol." I love that term! "Anarchy" expresses what dynamic allocation does to the semantics of the language quite well. > Also, allocating a lump of memory yourself as the heap has nasty > drawbacks. The size depends on how much memory is on the processor. > Less memory, less space - how do you allocate according to memory > availability? You can do it manually, but that stinks. > It means that all of this lump has been removed from the available > pool of memory. Every heap must be allocated some time. With Occam, you can place your allocation process on a transputer that's next to a disk (for swapping) or you can have a network of heap processes, one on each processor. In that sort of a system you can have a huge virtual address space with a distributed index. Overflowed heap proceses can store on nearby processors, and the "load" can be balanced or optimized concurrently with the client processes. > Why not let the system do the allocation for you? Because it's just as easy to do it yourself. > You can't provide a > server which will (de)allocate any arbitrary structure for you. You > run up against the protocol problems of occam at high speed there, > and the results are messy, because you can't specify arbitrary data > types. It's hard for me to believe that you haven't heard of the ANY protocol. Why do you post if you don't know what you're talking about? :James Disclaimer: The usual. -- :James P. Salsman (jps@CAT.CMU.EDU)
jps@cat.cmu.edu (James Salsman) (08/04/89)
In article <276@oscsuna.osc.edu> stein@pixelpump.UUCP (Rick 'Transputer' Stein) writes: > In article <5739@pt.cs.cmu.edu> jps@cat.cmu.edu (James Salsman) writes: > Well, I don't know if the Unidot C compiler available with the Trollius > OS is completely X3J11, but its a fair one. I insert Trollius calls > into my software when message passing is needed or kernel services > are required. All Trollius dependencies can be ifdef'd away if > portability to sequential execution is a requirement. Okay, well, I think you program at a coarser grain of parallelism than I do. I'm mostly concerned with natural language processing, information retrieval, multimedia databases, and implementing local and wide-area networks for those problems. I also work on production system based expert systems. Serially, I learned BASIC, Z-80, C and Lisp, in that order, but Occam is clearly superior for multiprocessing applications. Other parallel languages I've used are *Lisp and PARIS/C (on the Connection Machine.) Perhaps in a language debate like this we should talk about the applications involed. :James -- :James P. Salsman (jps@CAT.CMU.EDU)
motteler@umbc3.UMBC.EDU (Howard E. Motteler) (08/07/89)
In article <5752@pt.cs.cmu.edu> jps@cat.cmu.edu (James Salsman) writes: >Perhaps in a language debate like this we should talk about >the applications involed. A good point. I claim that occam is the ideal language for *teaching* concurrency, which is not to rule out other applications. Elegance, consistency, and solid foundations all count for for a lot in this context. We teach an undergrad class here, "Parallel Programming in occam," and especially the second time around, got quite a few impressive projects; students were allowed to suggest their own final project as an alternative to a default assignment. Some general observations: First, occam is terribly easy to learn; students can start writing concurrent code in the first week or so. There are several good texts available. The new generation of PC hackers take quickly to the the TDS environment; I guess to them it just seems like a fancy variation on Turbo Pascal. The strong usage checking helps a lot. The two most common errors are trying to commuincate via a shared variable, and having more than one process sending or receiving on a given channel; both of these give compile time errors. (Unless the students swith off usage checking!) Most importantly, occam/CSP is the right way to think about concurrency. The "atomic" action is a process; concurrency can be as fine or as coarse grained as we like, etc. I like to teach a little bit about dataflow right at the beginning, relating dataflow edges to occam channels, and nodes to processes. Program design is then often a two part process: first, finding a dataflow graph, and second coming up with a way to number channels and processes as components of one or more replicated PARs, so that channels corresponding to edges, and processes to nodes. The visual approach, thinking about concurrency as a dataflow graph, tends to keep students away from the black hole of trying to analyze all possible cases in a concurrent proram. (I had one *determined* state space analyzer, who inserted parameterized delays in every process, and tweaked the delays until processes interleaved in the order he expected. Probably the longest piece of code that occasionally managed to play "life" as has ever been written.) It may seem like I'm arguing for teaching dataflow as opposed to occam/CSP, but what I'm getting as is that dataflow programs map *into* occam in a very direct and natural way; occam in some sense is more general. Using occam, concepts of concurrency are no harder for students to learn than, say, recursion. Of course there are always a few students that have trouble with recursion too... at least you don't have to worry about that in an occam class! -- Howard E. Motteler | Dept. of Computer Science motteler@umbc3.umbc.edu | UMBC, Catonsville, MD 21228
gjap@ukc.ac.uk (G.J.A.Paul) (08/07/89)
In article <5751@pt.cs.cmu.edu> jps@cat.cmu.edu (James Salsman) writes: >In article <1948@harrier.ukc.ac.uk> arc1@ukc.ac.uk (A.R.Curtis) writes: > >> occam has compile-time allocated memory. It deals solely with *real* >> memory, and none of this nice run-time virtual memory. > >By "virtual memory" do you mean "allocatable heap storage" >or "memory paged out to disk"? Occam can do both. A >Transputer OS should provide a process for these functions. > By "virtual memory", *I* would mean "as much memory as my process requires, even if this is more than is physically attached to the processor". I, for one, would be interested in seeing how you would implement paged memory on a processor without an MMU in any way, shape or form. By "Transputer OS", I presume you mean a glorified loader, like CP/M or MS/DOS, which falls over when the user process falls over. >> [In reply to the idea of using process abstraction for an >> "allocation server" -jps] >> Ok, so how do you provide a memory allocation server to handle >> completely arbitrary types? You can't, can you? But I can do this in >> C, can't I? > >I can tell that you aren't an Occam programmer because you >don't know about CHAN OF ANY and PORT OF ANY -- these >protocols map everything back and forth into BYTEs. CHAN OF ANY does not "map everything back and forth into BYTEs". It's just a method of switching off the compiler's checking on the types of data sent over a channel. You can (probably) get away with treating it as a CHAN OF BYTE over a physical link, but over a soft channel, all sorts of things at the implementation level (such as block copies) mean that this just doesn't work. This is not a problem with the implementation of soft channels -- semantically there is no obligation for this to work. Treat CHAN OF ANY as a bag on the side, there to allow easier conversion of occam 1. In those days, all you had was a CHAN, and you sent an integer tag to indicate what was coming next. Now we have tagged protocols to take care of that sort of thing for us, and check for silly errors too, we don't need to resort to this low level. (Aside: I happen to know that Tony has been programming in occam since the occam 1 days. He certainly has heard of CHAN OF ANY.) >> [Tony made some comments about having to allocate all memory >> at compile time] > >Every heap must be allocated some time. With Occam, you can >place your allocation process on a transputer that's next to >a disk (for swapping) or you can have a network of heap >processes, one on each processor. In that sort of a system >you can have a huge virtual address space with a distributed >index. Overflowed heap proceses can store on nearby >processors, and the "load" can be balanced or optimized >concurrently with the client processes. Ah, by swapping, you meant moving unused bits of heap away. You certainly can do this, but you write the code to do it. What I want is to be able to run arbitrary-sized programs on processors with finite amounts of memory. This might mean swapping some of the code out as well. Not so easy. On machines which support paging and swapping, this sort of support is built into the operating system. (On future Transputers, it might be built into the chip.) It certainly isn't, and can't ever be, part of a programming language. The whole point is to hide such mechanisms from the programmer. Going back to the heap allocation problem, Tony was right when he said that you couldn't do it generally. There are two cases; single processor, and multiple processor: (1) You place the heap in the memory of the process that is using it, and use sequential routines called from the user process to manage it. In this case the heap management package consists of routines to allocate and free blocks from a large array. The array is passed to the heap routines so it can write information into it about block sizes and utilisation. So, your routine asks the heap manager for a block of a certain size, it returns an index into the array, and you RETYPE the array FROM that index FOR the size for the object you wish to put into the heap. However, beware, because RETYPE will cause a run-time error if you don't have the alignment right. You can't check for alignment -- that's a low-level detail unconnected with occam semantics. Possibly this alignment problem is an implementation problem with the current compiler. The best bet is probably to use an array of INTs because they're what the processor deals with best (in occam 1 it's all you had :-). But remember the size of an INT is processor dependent, not an absolute value, so don't insert any magic numbers in your code when you're trying to work out how much heap space you will need for, say, an array of BYTEs. None of this is very elegant. Each process therefore has its own heap, allocated at compile time. The advantage of having a heap is that you don't have to make decisions about the balance of memory utilisation between processes until run-time (when they are made for you by the inputs to the task). If each process has its own heap then this automatic balancing is lost, and the overhead of a heap is wasted -- just give each process a fixed-size array (this is what you are effectively doing). Actually, the heap could be shared between processes on the same processor, and requests for part of it communicated to a heap management process; the manager could return an index into the array. However, this isn't occam. It isn't possible to check statically that processes are not accessing memory outside their allotted areas, i.e. usage checking would have to be turned off at compile time. (2) For the multiple processor case, a memory server processor could be implemented. In this case, you add data to the heap, and collect data from it via communication over channels. You'll need a tagged protocol with tags for all of the different types of object you will want to put in the heap. All reads and writes require the overhead of channel communication, and the heap manager needs database management capabilities (to avoid problems caused by parallel updates, if more than one process uses the heap). However, because the tags are application dependent, you need to write a dedicated memory-server for each application. Not a general solution. >It's hard for me to believe that you haven't heard of the >ANY protocol. Why do you post if you don't know what you're >talking about? > >:James P. Salsman (jps@CAT.CMU.EDU) He does know what he's talking about, it's just that he's not prepared to make the compromises and take the short cuts you suggest when writing programs. Don't use CHAN OF ANY because you are too lazy to define a tagged protocol. It is interesting to note that Geraint Jones' and Michael Goldsmith's book, "Programming in occam 2" devotes about half a page to CHAN OF ANY (it has over 300 pages in total), and it says (page 59) "... the only circumstance in which internal anarchic channels are reasonable is when simulating a piece of hardware for testing the process which will drive it." The INMOS "occam 2 Reference Manual" takes a similar line -- it talks about communication with an "alien process". Its description of the retyping is only valid for physical links. There are a lot of problems still to be solved in this area, and we need semantically secure solutions. However, it is good to see some support for occam from the other side of the Atlantic! Godfrey Paul