🚀 go-pugleaf

In article <9105152020.AA15174@theory.TN.CORNELL.EDU> COS99284@UFRJ.BITNET (Luiz Felipe Perrone) writes:

     Process 1:
	   to.p2 ! h1; h2; s; r; i; b; x

     Process 2:
	   to.p2 ? h1; h2; s::buffer


These two message operations are not compabible.  Transputers require that a
receiver of a message expect a message of the same size as the sender is
sending.  The above would work if the Occam message operation translated to one
Transputer message operation, but it doesn't (and in general can't).

Rather, my guess is that in process 1 the Occam compiler is generating  a
separate "out" instruction for each element of the message list, which means
that in process 2 the element list must contain variables of the same type as
the arguments in process 1.

Hence for the above code, the effect is "undefined".

	-jeremy



     Placing STOPs here and there I have observed that Process 1 finishes and
   so it sends the message successfully. But what I'm trying to explain is why
   Process 2 never finishes. I have some wild guesses such as: the code the
   compiler generates for the input command in 2, is not appropriate to receive
   the message text (s::buffer) because the channel to.p2 was declared as CHAN
   OF ANY and not CHAN OF INT; INT; INT::()INT. Another one is that I may be
   experiencing some alignment problem due to retyping conversions.

     If someone knows why this happens or how I could send one message of varying
   length with any number of items of any type to a process that will see this
   message as a well defined header plus a text defined as an array of bytes
   of varying length, please let me know as soon as possible.

     I'm using this in the project of simulation kernel and I have to provide
   an elegant, flexible and easy to use interface between the simulator and
   the user's logical processes.

     Thank you all.

   ------------------------------------------------------------------------
   Luiz Felipe Perrone
   MSc student - COPPE - Dept. of Systems Engineering and Computer Science
   Universidade Federal do Rio de Janeiro - Brazil
   E-mail: COS99284@UFRJ (BITNET)
   Mailing address:  Rua Senador Vergueiro 157/305
		     Flamengo - Rio de Janeiro, RJ - Brazil
		     CEP 22230

   Phone number: (55)-(21)-5519063
   ------------------------------------------------------------------------
--
--
Jeremy Webber			   ACSnet: jeremy@chook.ua.oz
Digital Arts Film and Television,  Internet: jeremy@cs.adelaide.edu.au
3 Milner St, Hindmarsh, SA 5007,   Voicenet: +61 8 346 4534
Australia			   Papernet: +61 8 346 4537 (FAX)

In article <9105152020.AA15174@theory.TN.CORNELL.EDU> COS99284@UFRJ.BITNET (Luiz Felipe Perrone) writes:

>   Dear netters,
>
>     I have tried to use channels of protocol ANY in a very particular
>   situation and my results were very strange...


Greetings:

  The behavior of software and hardware channel communication in
in the Inmos OCCAM2 compiler is not identical.

  Here's why: In all channel transactions, each argument of an "!"  and
"?"  statement is an individual transaction.  The number and length of
the arguments in both the ? and ! must be absolutely *identical* on
both the sending and receiving end.  In your example the seven !
arguments are received by four ? arguments of differing length.
You'll find that the ! has completed, the first four ? arguments have
taken the value of the first four ! arguments, and that the ? is
waiting (forever) for its fifth argument.

  Curiously, you'll find that your code sample will run fine in a
configuration where the channel "to.p2" is a hard link, but not when
it is a soft link. Try it.  The implementation of channel
communication in OCCAM2 behaves differently on hard and soft channels.

  The simplest example of this behavior I know of is the following
buffer process which looks to be a universal, protocol-independent
buffer:

PROC byte.buffer( CHAN OF ANY in, out )

  BYTE data :

  WHILE TRUE
    SEQ
      in  ? data
      out ! data
:

Which works fine over hard channels, but will work on soft channels if
and only if the sending and receiving processes are actually sending
and receiving *individual* bytes.

The moral of the story: If you use OCCAM2, use explicit protocols -
even though they are cumbersome and restrictive.  It is hard to track
down bugs without them.

Note that ihe implementation of channel communication in the newly
released INMOS ANSI C compiler does *not* suffer from this curious
design flaw.

  The Best,

      -Louis.
--
Louis L. Whitcomb              llw@corwin.eng.yale.edu    ph: (203) 432-4237  
Yale Robotics Laboratory                                  fx: (203) 432-7481 
Department of Electrical Engineering, 1968 Yale Station, New Haven, CT 06520

In article <LLW.91May17095750@corwin.eng.yale.edu> llw@ghostwheel.eng.yale.edu (Louis L. Whitcomb) writes (about CHAN OF ANY):
>->  
>->    The behavior of software and hardware channel communication in
>->  in the Inmos OCCAM2 compiler is not identical.
>->  ...
>->    Curiously, you'll find that your code sample will run fine in a
>->  configuration where the channel "to.p2" is a hard link, but not when
>->  it is a soft link. Try it.  The implementation of channel
>->  communication in OCCAM2 behaves differently on hard and soft channels.
>->  ...
>->  The moral of the story: If you use OCCAM2, use explicit protocols -
>->  even though they are cumbersome and restrictive.  It is hard to track
>->  down bugs without them.
>->  
>->  Note that ihe implementation of channel communication in the newly
>->  released INMOS ANSI C compiler does *not* suffer from this curious
>->  design flaw.

I'm not sure what you think is the design flaw: the programs in question
are not guaranteed to work (by the occam2 Reference Manual).  The only
`unexpected' behaviour is that Inmos' occam2 compiler happens to produce
code which makes this invalid non-program do what its author expected in case
the communication is on hard channels.  It is _very_ hard to guarantee that
all incorrect programs do something unexpected; the usual contract with a
language implementor is that all correct programs should only do the
expected.

The moral extracted from the story is fine, though.  Think of CHAN OF ANY
as one of those horrible messes that you end up having to use when the
other end of the channel is attached to something other than an occam process
whose behaviour you are able to determine.
									g

In <LLW.91May17095750@corwin.eng.yale.edu> llw@ghostwheel.eng.yale.edu (Louis L. Whitcomb) writes:
>...

>The moral of the story: If you use OCCAM2, use explicit protocols -
>even though they are cumbersome and restrictive.  It is hard to track
>down bugs without them.

>Note that ihe implementation of channel communication in the newly
>released INMOS ANSI C compiler does *not* suffer from this curious
>design flaw.

I haven't looked at inmos C very closely.  How do they get round the 
"design flaw" (if that's what it is)?

Bryan

In article <1758@culhua.prg.ox.ac.uk> geraint@prg.ox.ac.uk (Geraint Jones) writes:
>I'm not sure what you think is the design flaw: the programs in question
>are not guaranteed to work (by the occam2 Reference Manual).  The only
>`unexpected' behaviour is that Inmos' occam2 compiler happens to produce
>code which makes this invalid non-program do what its author expected in case
>the communication is on hard channels.  It is _very_ hard to guarantee that
>all incorrect programs do something unexpected; the usual contract with a
>language implementor is that all correct programs should only do the
>expected.

A secure language implementation detects any violation of the language
definition, either at compile-time, or at run-time.  If a language cannot be
implemented in a secure manner, then the language design is flawed.  If a
language can be implemented in a secure manner, but a particular system fails
to do so, then the system design is flawed.

Jonathan

In article <7730@ecs.soton.ac.uk> dbc@ecs.soton.ac.uk 
(Bryan Carpenter) writes:

   In <LLW.91May17095750@corwin.eng.yale.edu> llw@ghostwheel.eng.yale.edu 
   (Louis L. Whitcomb) writes:
   >...

   >The moral of the story: If you use OCCAM2, use explicit protocols -
   >even though they are cumbersome and restrictive.  It is hard to track
   >down bugs without them.

   >Note that ihe implementation of channel communication in the newly
   >released INMOS ANSI C compiler does *not* suffer from this curious
   >design flaw.

   I haven't looked at inmos C very closely.  How do they get round the 
   "design flaw" (if that's what it is)?

   Bryan

Greetings Folks:

  In a previous post, quoted above, I incorrectly asserted that the
channel behavior in question (when sending and receiving processes
disagree on number or size of communication events) differed between
the OCCAM compiler and the new C compiler.  My more learned colleagues
remind me that the same behavior may be demonstrated in either
environment.

  Postings by various authors have covered this topic pretty well.

  The Best,

    -Louis.

--
Louis L. Whitcomb              llw@corwin.eng.yale.edu    ph: (203) 432-4237  
Yale Robotics Laboratory                                  fx: (203) 432-7481 
Department of Electrical Engineering, 1968 Yale Station, New Haven, CT 06520

In <1991May20.113104.25938@rodan.acs.syr.edu> greeny@wotan.top.cis.syr.edu (Jonathan Greenfield) writes:

>A secure language implementation detects any violation of the language
>definition, either at compile-time, or at run-time.  If a language cannot be
>implemented in a secure manner, then the language design is flawed.  If a
>language can be implemented in a secure manner, but a particular system fails
>to do so, then the system design is flawed.

This seems a bit hard on occam.  The ANY protocol fairly explicitly
*isn't* secure.  It's a low-level thing which, according to the
manual, is only supposed to be used for communicating with non-occam
peripherals and so forth.  For normal occam communication you're
expected to use checked protocols.

Bryan Carpenter

In article <LLW.91May17095750@corwin.eng.yale.edu> llw@ghostwheel.eng.yale.edu (Louis L. Whitcomb) writes:
>Note that ihe implementation of channel communication in the newly
>released INMOS ANSI C compiler does *not* suffer from this curious
>design flaw.

I don't know how you got this impression, but the ANSI C compiler
(which was released last August!) uses exactly the same method as occam,
and so behaves in the same way.

---
Conor O'Neill, Software Group, INMOS Ltd., UK.
UK: conor@inmos.co.uk		US: conor@inmos.com
"It's state-of-the-art" "But it doesn't work!" "That is the state-of-the-art".

In article <1991May20.113104.25938@rodan.acs.syr.edu> greeny@top.cis.syr.edu (Jonathan Greenfield) writes:
>A secure language implementation detects any violation of the language
>definition, either at compile-time, or at run-time.  If a language cannot be
>implemented in a secure manner, then the language design is flawed.  If a
>language can be implemented in a secure manner, but a particular system fails
>to do so, then the system design is flawed.
>
>Jonathan

The name `Anarchic protocol' indicates that it circumvents any
compiler checking. Once CHAN OF ANY is used, it is no longer a
secure language implementation.

Maybe we should remove CHAN OF ANY (:-)

---
Conor O'Neill, Software Group, INMOS Ltd., UK.
UK: conor@inmos.co.uk		US: conor@inmos.com
"It's state-of-the-art" "But it doesn't work!" "That is the state-of-the-art".

In article <1758@culhua.prg.ox.ac.uk> I wrote:

>  I'm not sure what you think is the design flaw: the programs in question
>  are not guaranteed to work (by the occam2 Reference Manual).  The only
>  `unexpected' behaviour is that Inmos' occam2 compiler happens to produce
>  code which makes this invalid non-program do what its author expected in case
>  the communication is on hard channels.  It is _very_ hard to guarantee that
>  all incorrect programs do something unexpected; the usual contract with a
>  language implementor is that all correct programs should only do the
>  expected.

In article <1991May20.113104.25938@rodan.acs.syr.edu> greeny@top.cis.syr.edu (Jonathan Greenfield) replies:

>  A secure language implementation detects any violation of the language
>  definition, either at compile-time, or at run-time.  If a language cannot be
>  implemented in a secure manner, then the language design is flawed.  If a
>  language can be implemented in a secure manner, but a particular system fails
>  to do so, then the system design is flawed.

But, but, but, come now.  Declaring a `CHAN OF ANY' gives the implementation
the right to assume that the programmer is going to use the channel properly.
That is what it says in the manual.  It is just like all the odd pragmas in
other languages (like those for turning off array bounds checks*) which you use
to assert to the compiler that _you_ the programmer will take responsibility
for guaranteeing a property which the compiler would otherwise be obliged to
check.  If you didn't want to make that guarantee, you didn't ought to have
declared the CHAN OF ANY.  

		( *  I don't know what the equivalent is for C programmers,
		     nor quite how to explain to C programmers what array
		     bounds checks are.					    )

The implementation can only be `secure' in the sense that it implements the
language as defined.  In any non-trivial language with while loops, you
will never get a mechanical guarantee from the compiler that the program
terminates.  In the same way, in any dialect of occam with CHAN OF ANY,
you will not get a mechanically checked guarantee of proper channel use.
And serve you right.  Of course, you might want a compiler for particular
applications to reject CHAN OF ANY declarations, but then it wouldn't be
an occam2 compiler, would it?
									g

In article <1772@culhua.prg.ox.ac.uk> geraint@prg.ox.ac.uk (Geraint Jones) writes:
>
>The implementation can only be `secure' in the sense that it implements the
>language as defined.

That's all that I said.  Perhaps I should not have implied more than that.
  
>In any non-trivial language with while loops, you
>will never get a mechanical guarantee from the compiler that the program
>terminates.  In the same way, in any dialect of occam with CHAN OF ANY,
>you will not get a mechanically checked guarantee of proper channel use.
>And serve you right.  Of course, you might want a compiler for particular
>applications to reject CHAN OF ANY declarations, but then it wouldn't be
>an occam2 compiler, would it?

Sure enough, you are correct.  That just says that "unsatisfactorily" matched
processes synchronizing via a CHAN OF ANY can be part of a *valid* occam
program.  (Analogously, as you point out, an infinite loop can be part of a
valid Pascal (for instance) program.)

Now, I'm really not familiar with the occam 2 definition of communication
over a CHAN OF ANY, but the fact that such programs are valid seems to lead
to a problem.  Namely, the parallel composition of two deterministic, valid
processes may yield one (overall) process when the composition is within a
single transputer, and may yield a completely different process (STOP, for
example) when the composition involves two transputers.  

Now I haven't checked, but I have been of the impression that the occam 
definition has intended to make PAR and PLACED PAR identical in composing 
two or more processes into a single (overall) process.  (That is, the only 
difference should be in the system's implementation of the composition.  
Abstractly, the composition is identical.)  If this is the case, then the
system would appear to be doing something to violate the definition of 
occam.

If, on the other hand, occam does prescribe such a differentiation, then
the system is fine, but (at least this feature of) occam sure is a mess.
I know I wouldn't want to be working on the semantics for such language
features (so tied to implementation details).

Any thoughts shedding further or better light on this question shall be
greatly appreciated.


Jonathan