Closed kazzmir closed 1 year ago
Also just a minor thing I guess, but the spec uses a condition for the br l_i
rule that is tautological in that l_i
is defined to be the same as l*[i]
.
I guess the condition should be (if 0 <= i < |l*|)
Well I see why it works in the reference interpreter actually. It is because the interpreter uses I32.ge_u
, so any negative number will most likely be larger than the length of the list of targets.
| BrTable (xs, x), Num (I32 i) :: vs' ->
if I32.ge_u i (Lib.List32.length xs) then
vs', [Plain (Br x) @@ e.at]
else
vs', [Plain (Br (Lib.List32.nth xs i)) @@ e.at]
Yes, the input value to br_table
is interpreted as a 32-bit unsigned int.
I agree, therefore the spec seems to not specify this.
The abstract syntax for const
is supposed to only allow positive numbers, and as noted in that section, all signed uses perform explicit reinterpretation via the signed meta operator.
However, there is indeed a bug there, because the AST grammar for const
specifies iN instead of uN for integer immediates. Fixed in #1577.
The spec says
l*
for thebr_table
instruction here is[$1 $2]
, with indices [0, 1], andl_N
is$default
. The two rules forbr_table
based on the valuei
, which is-5
here, are:In this case,
i < len(l*)
is true since -5 < 2, which would mean the machine would try to lookupl*[-5]
, which is meaningless.The reference spec interpreter seems use the
$default
label here, which suggests it requires that i >= 0 before thebr l_i
rule is invoked.