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

Microwasm: Why does BrIf have an else_ ? #1225

Closed
tiborvass opened this issue Mar 4, 2020 · 1 comment
Closed

Microwasm: Why does BrIf have an else_ ? #1225

tiborvass opened this issue Mar 4, 2020 · 1 comment

Comments

@tiborvass
Copy link
Contributor

Out of curiosity I was wondering why the BrIf instruction has an else_ target when the it could simply be moving on to the next instruction.

arkpar pushed a commit to paritytech/wasmtime that referenced this issue Mar 4, 2020
This commit removes the dependency on `byteorder::ReadBytesExt`, which can't be
used from `no_std`, which is how we're building the `byteorder` crate.

The fix is to simply offset into the slice as needed rather than using a
`std::io::Cursor`.

Fixes bytecodealliance#1225.
@eira-fransham
Copy link
Collaborator

eira-fransham commented Mar 4, 2020

Great question! So basically, it's a way to make dealing with control flow easier. So basically in Wasm there are 2 kinds of intra-function control flow - conditional (you might jump or you might not) and unconditional (you always jump). However, since these are both control flow, all the same conditions apply. If you had a br_table with 1 target and 1 default, that's exactly the same as a br_if except that it jumps unconditionally, for example. So we make all control flow unconditional and we model conditional control flow by creating a new block directly after the current one and then emitting an unconditional jump where the "then" is the Wasm br_if's target, and the "else" is that newly-created block. By unconditional I here mean that we must jump, but where we jump is defined at runtime. Doing it this way means that we don't have any special-cases, we handle both unconditional and conditional control flow the same, which has a few added benefits. For example, unconditional control flow where one of the targets is the location directly after the jump (for example, a br or br_table followed immediately by an end) can be compiled to "fall through" just as br_if is, which produces better code while only having a single code-path.

Hope that helps, I'm actually writing up some documents describing some of the design decisions, constraints, and proposals for Lightbeam over at https://github.com/paritytech/lightbeam-stammtisch, but it's very unfinished and doesn't have a great deal of information on Microwasm itself right now.

Since this is a question and not an issue, I'm going to close it, but if you have further questions about Lightbeam's design I highly recommend that you post an issue over at lightbeam-stammtisch since it will help me learn what I haven't explained properly, or other holes that need to be filled.

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