[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: CHAN variants
B.M. Cook writes:
> Is it ... a sender to several receivers, synchronized so that all must have
> received the message before the transaction completes and the sender
> continues? [And, if it's a hardware bus this is easily achieved.]
Not quite. A sender to several receivers, but the communication is an atomic
action: the event is simultaneous.
Indeed, as I have already mentioned in our private conversations, I am
introducing a new SYNC constructor to "merge" events. This is intimately
related to the COMMON chan (I think that *COMMON* is the answer to my
original question), as well as to some of the ideas that we discussed last
year (ASS, or MASS assignment).
What is not yet clear in "ocham" and "HCSP" is what should be taken as
primitive, although SYNC is a very strong candidate as one such. I won't
say more about that until I have explored all the implications further.
> If so, isn't this a multicast operation?
A *synchronised* multicast, perhaps.
> How about keeping occam channel identifier declarations as they are but
> allowing multiple, parallel output ...
>
> CHAN OF XXX a, b:
> PAR
> XXX x:
> SEQ
> a ? x
> -- etc.
>
> XXX y:
> SEQ
> b ? y
> -- etc.
>
> SEQ
> a,b ! value -- I suppose this is equivalent to
> -- etc. -- PAR
> -- a ! value
> -- b ! value
[N] CHAN OF blah common :
PAR i = 1 FOR N-1
common[i] ! v
common[i] ? x[i]
or
(N - 1)
|| ((common[i] ! v -> Q ) || (common[i] ? x -> P ))
0 i i
doesn't quite work because the events constituting channels are usually taken
as disjoint. The process above engages in N separate events rather than a
single event. (There are other *far stronger* reasons for introducing
merged events: since that notion is present anyway, it is the natural to
use it to describe "COMMON" channels.)
Replace PAR by SYNC above, and we may have a law of ocham/HCSP.
Simple tentative examples of the sort of thing that I am wondering about here
are:
COMMON CHAN OF bits common:
SYNC
common ! v
common ? x
common ? y
Note that writing
COMMON CHAN OF ECL common: might not be wrong if we had a
SYNC "wired-OR" ECL signal. Actually, I
common ! v1 think that this should be illegal
common ! v2 (aka bus contention if v1 <> v2).
common ? x And the ECL implicit OR gates should
be made explicit....
Although
COMMON CHAN OF blah c: [2] CHAN OF blah c:
SYNC SYNC
c ! v is equiv to c[0] ! v
c ? x c[1] ! v
c ? y c[0] ? x
c[1] ? y
I don't think that the RAZOR means that we should use a cumbersome verbose
notation for a simple idea. Of course, in software/hardware codesign,
an "ocham" compiler would make this transformation when it was emitting
"software" rather than "hardware". Of course, ocham may turn out to be
occam2.83215? :-)
All this is tentative: "HCSP" and "ocham" is still evolving. I don't want to
say too much about it in public yet until I am convinced that it all hangs
together, is self consistent, and doesn't lead into any black holes. In
particular, HCSP has to be rather radical in its denotational semantics, and
I have to convince myself that it works properly...
Adrian
PS. Any advance on COMMON ? Jeremy Martin suggested MULTI. Any more from the
rest of you occamists, and have you all been subverted into Javaists?
--
Adrian Lawrence.
adrian.lawrence@xxxxxxxxxxxxxx or adrian.lawrence@xxxxxxxxxxxxxxx
MicroProcessor Unit | Computing Laboratory,
13, Banbury Road, | Wolfson Building,
Oxford. OX2 6NN. | Parks Road, Oxford.
UK. | OX1 3QD. UK.
Voice: (+44)-1865-273274,(+44)-1865-283526 Fax: (+44)-1865-273275