Thread View: comp.sys.transputer
3 messages
3 total messages
Started by IAN
Mon, 10 Apr 1989 13:27
Re: what makes occam so good?
Author: IAN
Date: Mon, 10 Apr 1989 13:27
Date: Mon, 10 Apr 1989 13:27
83 lines
5075 bytes
5075 bytes
In article <1663@etive.ed.ac.uk> Nick Rothwell <mcvax!ukc!etive!lfcs!nick@net.uu.uunet> writes: >OCCAM has a particular model of concurrency which happens to map >fairly closely to the way you plug transputers together, and their >hardware capabilities. If you try to implement it on hardware which >doesn't give you these things, you have to emulate, and take a huge >performance hit. Look at the OCCAM evaluation kit, or whatever. I >agree that it was a good idea to put that out in advance, but I don't >know how many people were converted to what they saw, plus the promise >of fast hardware. Any comments? The occam model of concurrency maps well onto any loosely coupled multiprocessor system. The code running on each processor can be written in the sequential subset of occam. >These kinds of rules are just simple rewrite rules on abstract syntax. >You get them in any language, where A+B == B+A (side-effects apart). Yes, but most languages don't have very many such rules, and they usually have semantic constraints. In occam, these rules *define* the semantics. For instance, taking your example, in occam (A+B) = (B+A) is *always* true, by definition - there are no side effects. >I don't see anything which makes OCCAM a formal "calculus" of any kind. >I haven't seen any work which shows it to be mathematically rigorous. >For a formal approach to concurrency and behaviour, I'd rather look at >something like Milner's Calculus of Communicating Systems which has >concepts of observational and behavioural equivalence. No doubt Milner's CCS is indeed a more general tool to describe a wide variety of models of concurrent behaviour, but that is not the intention of occam. It is intended to be a programming language. See the discussion in the last chapter (last section, I think) of Hoare's CSP book. >You get that from any non-procedural language. True. I like non-procedural languages too. >If you can access things by address, then you can get aliasing problems, >like those you dismissed above. Low-level features are often necessary, >but they *always* violate your language model and invalidate formal >resoning. I agree. That is why PORTs should always be used to access memory mapped peripherals. The address of each port is fixed, and the compiler performs the same useage checking as if the port was a channel. RETYPES allows the memory allocated to a variable or array to be accessed under the guise of a new variable or array of a different type. There is no aliasing, as the old name goes out of scope. The total size (in bytes, words or whatever) of the RETYPED variable can not exceed that allocated for the original one. The major uses of this facility are to allow the programmer to construct 'heaps' of objects of different types, or to implement record structures, while preserving type checking. The need for this would go away if occam supported more abstract data types, as one day I hope it will. >Please clarify. Suppose I define a process/procedure/whatever called FOO. >I then define another one called FOO, and inside that, reference FOO. If my >OCCAM system shifts from being non-recursive to being recursive, my program >breaks. Recursion reflects the name-space semantics of the language. True. I must admit I glossed over that, but I didn't actually say that the semantics of the language would be unaltered. While at the moment, a name does not come into scope until its declaration is complete, it would have to come into scope at the beginning of its declaration to permit recursion. There is also the issue of how you get mutual recursion. For instance, if PROC A calls B() and PROC B calls A(), then whichever way round you declare them (at the same level) one of the calls will refence a name that is out of scope. The usual solution is to alter the syntax to allow a 'stub' declaration before the main one, just declaring the procedure name and its parameter list. >I'd actually love to see an OCCAM with a polymorphic/abstract type discipline. So would I. +-----------------------------------------------------------------------------+ | Ian Glendinning JANET: ian@UK.AC.soton.esp.v1 | | Fidelio Software GmbH BITNET: ian%UK.AC.soton.esp.v1@AC.UK | | Widenmayerstrasse 6 UUCP: ...!mcvax!sot-cm!igl | | D-8000 Muenchen 22 other: ian@v1.esp.soton.AC.UK | | West Germany Phone: +49 89 2123080 | +-----------------------------------------------------------------------------+
Re: what makes occam so good?
Author: Nick Rothwell
Date: Thu, 13 Apr 1989 10:11
Date: Thu, 13 Apr 1989 10:11
39 lines
2834 bytes
2834 bytes
In article <8904101227.AA05713@uk.ac.ox.prg> IAN@vax1.esprit.southampton.ac.uk writes: >No doubt Milner's CCS is indeed a more general tool to describe a wide >variety of models of concurrent behaviour, but that is not the intention >of occam. It is intended to be a programming language. Fair enough. I was probably getting a little wound up by the way that OCCAM keeps getting referred to as a "calculus", as if there is something magically formal about it that sets it completely apart from other languages. It *does* have some nice (and important) semantic properties, but I certainly would not call it a formal language; it is a programming language, like you say, nothing more, nothing less. Actually, I quite like OCCAM. It provides a good way of building frameworks and mechanisms to handle the concurrent part(s) of an application. However, it totally fails to provide some of the important aspects of a software system: recursion, abstraction, data structuring, etc. In a recent project we tied 20000 lines of C (a compiler for an abstract language, abstract code generator, interpreter, and so on) with some OCCAM to provide a communications base. Writing the compiler in OCCAM would have been a virtual non-starter. Writing it in C was bad enough, given that the prototype was in ML. The main reason for OCCAM's failure, I think, is the closed world philosophy that went along with it. INMOS wanted everybody to program entirely in OCCAM under the TDS on their Sage computers. Everything else was "alien" - even files. We threw the OCCAM out of our project and used C instead, because OCCAM's little world was so completely nonstandard and different to everything else. Using C and the 3L tools, we can drive the development process from a Sun. Had INMOS brought out a "batch" OCCAM compiler, and believed in conventional machines and file systems, things might have been different. What do other people feel? >| Ian Glendinning Nick. -- Nick Rothwell, Laboratory for Foundations of Computer Science, Edinburgh. nick@lfcs.ed.ac.uk <Atlantic Ocean>!mcvax!ukc!lfcs!nick ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ...while the builders of the cages sleep with bullets, bars and stone, they do not see your road to freedom that you build with flesh and bone.
Re: what makes occam so good?
Author: Ben Lian
Date: Sun, 16 Apr 1989 14:38
Date: Sun, 16 Apr 1989 14:38
91 lines
5554 bytes
5554 bytes
In article <1756@etive.ed.ac.uk> nick@lfcs.ed.ac.uk (Nick Rothwell) writes:
> Actually, I quite like OCCAM. It provides a good way of building frameworks
>and mechanisms to handle the concurrent part(s) of an application. However,
>it totally fails to provide some of the important aspects of a software
>system: recursion, abstraction, data structuring, etc.
My apologies if the following sounds like self-promotion but I thought that
some people might be interested.
When occam first appeared on the scene, I was happy with the way it reflected
the CSP model, but I wasn't happy with the lack of high level facilities. So
a couple of years ago I decided to design my own CSP-based language. After
a long and often painful gestation period I finally produced IMPALA (IMperative
PArallel LAnguage). It contains a fairly simple but powerful type system in
which one can create structured types (arrays, products, unions), and in which
the numeric types form a subtype hierarchy. There are also facilities for the
implementation of abstract data types. Other features include two kinds of
subprograms, processes and functions, which may be generic, and functions may
also be recursive. I won't bore you with further gory details except to say
that a compiler is currently under development, resident on a VAX/UNIX
system, cross-compiling for the transputer.
Designing and implementing a language to get what I want is, I guess, somewhat
masochistic. It's definitely doing things the hard way!
> In a recent project
>we tied 20000 lines of C (a compiler for an abstract language, abstract
>code generator, interpreter, and so on) with some OCCAM to provide a
>communications base. Writing the compiler in OCCAM would have been a virtual
>non-starter. Writing it in C was bad enough, given that the prototype was
>in ML.
Oh yes! I mentioned in an earlier posting that I have an occam compiler
written in occam, and that it was not a sight for the faint of heart. A
little bird in INMOS tells me that the current occam compiler supplied as
part of the TDS version D700D is written in occam. For various reasons,
the next generation of occam compilers will be, umm, are, written in C.
The reason given directly is that of portability, but I suspect that
maintenance is also a bit of a headache.
By the way, don't get me wrong -- I'm not knocking occam. It has its place
in the scheme of things.
> The main reason for OCCAM's failure, I think, is the closed world
>philosophy that went along with it. INMOS wanted everybody to program
>entirely in OCCAM under the TDS on their Sage computers. Everything else
>was "alien" - even files. We threw the OCCAM out of our project and used C
>instead, because OCCAM's little world was so completely nonstandard and
>different to everything else. Using C and the 3L tools, we can drive the
>development process from a Sun. Had INMOS brought out a "batch" OCCAM
>compiler, and believed in conventional machines and file systems, things
>might have been different. What do other people feel?
Yes, agreed. The TDS seems to only get in the way. Maybe I've been
using UNIX for too long and can't get used to a different way of working,
I don't know. When I wanted to play around with the transputer instruction
set, I found myself preferring to use the assembler in Logical System's
Logical System's Transputer Toolset (great stuff!) rather than use occam2's
GUY construct.
>Nick Rothwell, Laboratory for Foundations of Computer Science, Edinburgh.
> nick@lfcs.ed.ac.uk <Atlantic Ocean>!mcvax!ukc!lfcs!nick
I might just add that readers interested in seeing the sort of program
transformation possible with occam programs should try to get hold of
the Oxford PRG technical report by Bill Roscoe and Tony Hoare titled
"The Laws of Occam Programming" (Technical monograph PRG-53, February
1986). Admittedly, the language used is a subset of occam 1 -- timing,
priority, vectors, constants, replicators and named processes are
omitted -- but it is interesting nonetheless. The ability to transform
a program/construct into a semantically equivalent one is is useful for
"...transforming programs to make them more efficient, and transforming
programs to a restricted syntax for special applications." The latter
is demonstrably feasible, while the former and the more general goal of
proving programs correct are still somewhat problematical.
Ben Lian
-----------------------------------------------------------------------
Benjamin Y H Lian ACSnet: ben@tasis.utas.oz
Dept. of EE & CS ARPA : ben%tasis.utas.oz.au@uunet.uu.net
University of Tasmania BITnet: munnari!tasis.utas.oz!ben@
GPO Box 252C uunet.uu.net
Hobart, Tasmania 7001 UUCP : {enea,hplabs,mcvax,uunet,ukc}!
A U S T R A L I A munnari!tasis.utas.oz!ben
-----------------------------------------------------------------------
Thread Navigation
This is a paginated view of messages in the thread with full content displayed inline.
Messages are displayed in chronological order, with the original post highlighted in green.
Use pagination controls to navigate through all messages in large threads.
Back to All Threads