Is this a Compiler Bug? Is this legal OCCAM? (No parentheses)
Mario Veraart
I have written an OCCAM program that contains the following segment
(taken from the original large program)
------------------------------------------------------
#INCLUDE "hostio.inc"
#USE "hostio.lib"
PROC ifand.entry (CHAN OF SP fs, ts, []INT free.memory)
VAL INT size IS 10:
[size][size]INT bitmap:
INT x,y:
SEQ
so.write.string.nl (fs, ts, "Testing IF clause with AND and no ()")
x := 5
y := 2
IF
(x >= 0) AND (x < size) AND
(y >= 0) AND (y < size)
SEQ
bitmap[y][x] := 0
TRUE
SKIP
so.exit (fs, ts, sps.success)
:
--------------------------------------------------------
My problem is with the boolean clause in the IF statement.
If you look closely there are no parentheses used to make
a legal OCCAM expression, yet the compiler does not complain.
When I indent the second line of the expression the same result.
When I put parentheses so it is a legal OCCAM expression the
same code is generated.
There are two thing wrong with the clause:
-- no parentheses
-- no indent
Does anybody know what is the cause for this problem?
This is the code that the compiler makes
-- occam 2 compiler Version 2.01.01 (18:33:38 Feb 27 1991) (SunOS-Sun4)
-- Compiling (T8,HALT) "ifand.occ"
L0: -- section label -- Stub for library call so.exit
.BYTE #20 #20 #20 #20 #20 #20
L1: -- section label -- Stub for library call so.write.string.nl
.BYTE #20 #20 #20 #20 #20 #20
L2: -- section label
.BYTE #FF #C9 #9A #3B
L3: -- section label
.BYTE #54 #65 #73 #74 #69 #6E #67 #20 #49 #46 #20 #63 #6C #61 #75 #73
.BYTE #65 #20 #77 #69 #74 #68 #20 #41 #4E #44 #20 #61 #6E #64 #20 #6E
.BYTE #6F #20 #28 #29
**** [ File "ifand.occ" ]
Line 4: PROC ifand.entry (CHAN OF SP fs, ts, []INT free.memory)
L4: -- section label
ajw -5
ldc L2 - L5
ldpi
L5:
stl 4
**** [ declaration local to ifand.entry ]
Line 5: VAL INT size IS 10:
**** [ declaration local to ifand.entry ]
Line 6: [size][size]INT bitmap:
**** [ declaration local to ifand.entry ]
Line 7: INT x,y:
Line 8: SEQ
Line 9: so.write.string.nl (fs, ts, "Testing IF clause with AND and no ()")
ldl 10 -- vsp
ldnlp 100
stl 1 -- parameter
ldc 36
stl 0 -- parameter
ldc L3 - L6
ldpi
L6:
ldl 7 -- ts
ldl 6 -- fs
call L1 -- Call so.write.string.nl
Line 10: x := 5
ldc 5
stl 3 -- x
Line 11: y := 2
ldc 2
stl 2 -- y
Line 12: IF
Line 13: (x >= 0) AND (x < size) AND
Line 14: (y >= 0) AND (y < size)
ldc 0
ldl 3 -- x
gt
eqc 0
cj L8
ldc 10
ldl 3 -- x
gt
cj L8
ldc 0
ldl 2 -- y
gt
eqc 0
cj L8
ldc 10
ldl 2 -- y
gt
cj L8
Line 15: SEQ
Line 16: bitmap[y][x] := 0
ldl 2 -- y
ldc 10
csub0
ldc 10
prod
ldl 3 -- x
ldc 10
csub0
add
ldl 10 -- bitmap
wsub
ldc 0
rev
stnl 0
j L7
L8:
Line 17: TRUE
L7:
Line 18: SKIP
Line 19: so.exit (fs, ts, sps.success)
ldl 10 -- vsp
ldnlp 100
stl 0 -- parameter
ldl 4 -- constptr
ldnl 0
ldl 7 -- ts
ldl 6 -- fs
call L0 -- Call so.exit
**** [ Return from routine ifand.entry ]
ajw 5
ret
L9: -- section label
.BYTE #20 #20 #20 -- add 3 bytes for alignment
-- Module code size is 132 bytes
--
Mario Veraart TNO Physics and Electronics Laboratory
email: ri...@fel.tno.nl The Hague The Netherlands
"If all else fails, show pretty pictures and animated videos,
and don't talk about performance", David Bailey
Stephen Clarke
This is legal occam. See the "Occam 2 Reference Manual", page 48:
"... parentheses may be omitted between expressions containing
adjacent AND and OR operators".
This is because AND and OR always evaluate left-to-right, so the order of
evaluation of
x AND y AND z
is unambiguous.
>Mario Veraart TNO Physics and Electronics Laboratory
>email: ri...@fel.tno.nl The Hague The Netherlands
Cheers,
Stephen Clarke
---
Stephen Clarke INMOS Ltd, Bristol | EMail(UK) ste...@inmos.co.uk
The opinions above are my personal | Internet: ste...@inmos.com
views and do not reflect INMOS policy. |
Roger Peel
There's no problem!
Occam uses parentheses to define the order of evaluation of expressions
which contain non-associative operators. Since groups of Boolean AND and OR
operators are truly associative, no parentheses are necessary and, thus, your
example is legal. See the INMOS Occam2 Reference Manual, section 7.2.6.
Notice, however, that the expression is evaluated from left-to-right,
and stops as soon as it is seen the be FALSE. You should therefore put
the most likely failure cases first for speedy execution.
The manual entry on "Continuation Lines" in the initial section states that
lines may be broken after an operator - AND in your case. Since the first
part of your Boolean expression ends in an AND, there is no way that it could
be confused with two separate conditional expressions, with the intervening
conditional process omitted.
I hope that this restores your confidence in Occam! At least it has no "=="
to forget about!!
Roger M.A. Peel
Department of Electronic and Phone : +44 483 509284 (0483 from UK)
Electrical Engineering Fax : +44 483 34139
University of Surrey Telex : 859331
Guildford JANET : R.P...@uk.ac.surrey.ee
Surrey GU2 5XH UUCP : ...mcsun!ukc!ee.surrey.ac.uk!R.Peel
United Kingdom