Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

branching to invalid label? #270

Closed
wanderer opened this issue Mar 31, 2016 · 7 comments
Closed

branching to invalid label? #270

wanderer opened this issue Mar 31, 2016 · 7 comments

Comments

@wanderer
Copy link

What is (br 0) branching too?

(module
  (func $if (result i32)
    (local $i i32)
    (if
      (i32.const 1)
      (br 0)
     )
     (get_local $i)
  )
  (export "if" $if)
)

There are no blocks or loops so there are no labels.

@ghost
Copy link

ghost commented Mar 31, 2016

@wanderer To the end of the implicit if-then block, so to the end of the if operation.

@wanderer
Copy link
Author

thanks @JSStats. There is no special if-then block in the binary spec, so it must be getting converted to this

(module
  (func $if (result i32)
    (local $i i32)
    (if
      (i32.const 1)
      (block (br 0) ) 
     )
     (get_local $i)
  )
  (export "if" $if)
)

But why is it inserting a block? Shouldn't the s-expressions be 1-1 with the binary?

@ghost
Copy link

ghost commented Mar 31, 2016

@wanderer (if (cond) (exp1) (exp2)) is just an assembler short-hand for (if (cond) (then (exp1)) (else (exp2))), where the then and else are blocks.

@wanderer
Copy link
Author

@JSStats I think i see that. I'm picking it apart with the sexpr-wasm-prototype. So something like

    (if
      (i32.const 1)
      (i32.const 1)
     )

Gets no block inserted. But

    (if
      (i32.const 1)
      (br 0)
     )

gets turned into

    (if
      (i32.const 1)
      (block (br 0))
     )

Which is annoying because there must be some rules to decide whether or not to insert a block. Also it means s-expressions are not 1-1 with the binary

@ghost
Copy link

ghost commented Mar 31, 2016

@wanderer Oh, the sexpr-wasm-prototype de-facto standard is out of sync with the spec or design, and still uses a legacy if so translates. sexpr-wasm-prototype looks at block uses and does some simplifications.

@wanderer
Copy link
Author

thanks @JSStats for taking time to explain

@binji
Copy link
Member

binji commented Mar 31, 2016

@JSStats No, that's wrong. AIUI, the spec was updated before the demo to add blocks to the then and else branches, in preparation for the transition to the postorder format. But the binary format was not similarly updated. I modified sexpr-wasm-prototype so it could take this discrepancy into account (AFAIK the other binary translators don't bother).

ngzhian added a commit to ngzhian/spec that referenced this issue Nov 4, 2021
{i8x16,i16x8,i32x4}_{any_true,all_true}

v128.bitselect is used in the tests (simd_boolean.wast) so implemented
here using a new AST node, Ternary. Bitselect is the only ternary
instruction now.
dhil pushed a commit to dhil/webassembly-spec that referenced this issue Oct 3, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants