-
Notifications
You must be signed in to change notification settings - Fork 1.2k
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
Comments
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.
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 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 |
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.
The text was updated successfully, but these errors were encountered: