Open vladikcomper opened 2 years ago
Further testing proves it's likely an operator priority issue:
If gameRevision
is set to 3
, the expression is now truthy:
21/ 0 : =$2 gameRevision = 3
22/ 0 : =$1 allOptimizations = 1
23/ 0 : =$1 removeJmpTos = 0|gameRevision=2|allOptimizations
This is because due to incorrect operator order it's resolved as follows:
0|gameRevision=2|allOptimizations
0|(gameRevision=(2|allOptimizations))
0|(gameRevision=3)
0|1
1
From what I can tell, this is intended behavior, since it is documented that the comparison operators have lower precedence; but it is counter-intuitive, and I will fix this so it works as one might expect. For the record, this line:
0|gameRevision=2|allOptimizations
gets parsed as
(0|gameRevision)=(2|allOptimizations)
and not as
0|(gameRevision=2)|allOptimizations
However, fixing this will involve rewriting the expression parser, because unary minus operator is implemented in a hackish way and does not have a precedence of its own. effectively sharing it with the binary minus operator. This means that I can make at most one of these work with reassigned priorities:
if a=-1
if a=b-1
Unless I rewrite the expression parser, that is.
In the interim, I updated the disassembly to use parenthesis to get the correct result.
I've noticed a serious bug when compiling s2disasm with the recent version of AS (v.1.42 beta [build 211] at the time of writing).
Some of the assembly options (defined as variables) were broken due to incorrect evaluation of their expressions.
Take the following example:
The last variable,
removeJmpTos
, should obviously evaluate to$1
(true) given the expression:gameRevision
is indeed2
, and if that's not enough,allOptimizations
are also non-zero. However, it's mistakenly evaluated as$0
(false).Interestingly, the following expressions still work as intended:
and:
Which leads to a conclusion that it's either a bug in expression evaluator, or priorities of
=
and|
operators are incorrect, as if the expression in question were internally resolved to this instead:The incorrect ordering of operators would explain the bug, as it would make sense that this expression is falsy: it's not true that
gameRevision=(2|allOptimizations)
, because2|allOptimizations
evaluates to3
andgameRevision
obviously equals to2
in the example above.