[CCC DEV] Concerning commit 6894(ish)

Adam Sampson ats at offog.org
Tue Jul 20 11:10:27 BST 2010


Michael Pirrone-Brusse <pirronm at allegheny.edu> writes:

> It would be a break from the wiring API to not do that in
> wiring.module, but I'm starting to think keeping to the wiring API
> isn't so much worth it.

Yes -- you'll have to change stuff in the Wiring API that isn't doable
in occam. Global variables and functions that aren't functions will be
the two big changes. (It's also worth noting that Wiring is not exactly
a shining example of good C++ API design!)

The reason global variables aren't permitted is that, in the original
implementation of occam on the Transputer, a program might be running
across several physical processors that don't share memory -- so there's
nowhere to put changeable global variables, even if the compiler could
prove you were using them safely.  You can get the same effect by
passing the variable explicitly by reference to the PROCs that need it:

  PROC set.verbosity (VAL INT level, INT verbosity.level)
    verbosity.level := mangle (level)
  :

  PROC show.message (VAL []BYTE message, INT verbosity.level)
    ...
  :

VAL INT is passed by value, so you can't change it; just INT is passed
by reference, so you can.

(It's worth noting that if you just need a global-ish variable for a
program you're writing, rather than for things you're exposing from a
library, you can use nested PROCs to give you an explicit scope for the
variable:

  PROC my.program ()
    INT counter:

    PROC do.something ()
      SEQ
        ...
        counter := counter + 1
    :

    ...  other PROCs

    SEQ
      counter := 0
      do.something ()
      ...
  :
)

In occam, a FUNCTION should be a function in the mathematical sense --
when called with the same parameters it must always return the same
value. It's quite legitimate for an occam compiler to optimise:
 
  x := read.port (42)
  y := read.port (42)

into:

  x := read.port (42)
  y := x

when read.port is a function. The current compiler will go some way
towards trying to ensure that this is the case, but it's not very smart
about use of FFI calls or PORTs.

This means that most C "functions" that return a value should be
translated into PROCs with a RESULT parameter:

  PROC read.port (VAL INT port, RESULT BYTE value)
    ...
  :

  read.port (42, x)

You can see other examples of this in the POSIX bindings in file.module,
and anything generated by SWIG (e.g. occSDL.module).

-- 
Adam Sampson <ats at offog.org>                         <http://offog.org/>




More information about the developers mailing list