conor@lion.inmos.co.uk (Conor O'Neill) (02/01/91)
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".