🚀 go-pugleaf

I would like to correct an error in the January 1990 edition of the
occam user group newsletter.

G. De Pietro and U. Villano have written an excellent discussion
on using the high priority timer from within a low priority process.
However, they make an error in one of their examples.
On page 40, they provide a FUNCTION hi.time() as follows:

INT FUNCTION hi.time()
  INT time :
  VALOF
    SEQ
      GUY
        LDC 0
        CJ .change.priority
        :read.timer
        LDTIMER
        STL time
        STOPP
        :change.priority
        LDC -10              -- this should be LDC -9
        LDPI
        STL -1
        LDLP 0
        RUNP
    RESULT time
:

The 'LDC -10' is designed to indicate the number of bytes from
the instruction following the LDPI, back to the label :read.timer
If you actually count the number of bytes, this should be LDC -9.

They make a similar dangerous assumption in their routine `hi.delay' on page
42, relying on the compiler generating a specific number of bytes of
code for a particular construct. Obviously different compilers could
create different code sequences, so to be safe, probably the entire
routine should be written in assembler.
In a similar vein, the routine `hi.delay' on page 41 relies on a
particular workspace allocation strategy.

(I should point out that the forthcoming occam compiler includes
an improved ASM construct which fixes many of the problems of GUY code.
GUY code is still supported, however.)

There is another point which should be noted; `hi.time()' is actually
an `impure' function, in that it returns a different result every time it is
called. This breaks occam semantics (note that if it had been written
completely in occam the compiler would have checked this), and so great
care should be taken with it. The routine should really have been
written as a procedure.

---
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".