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.

Sign up for GitHub

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

Jump to bottom

Move arities from branches to blocks #741

Closed
wants to merge 3 commits into from
Closed

Move arities from branches to blocks #741

Changes from all commits
Commits
Show all changes
3 commits
Select commit Hold shift + click to select a range
e4d33d8
Remove arities for call/return; move arities from branches to blocks
rossberg Aug 2, 2016
ac831ce
Text tweak
rossberg Aug 2, 2016
ffd5859
Split off call/return arities
rossberg Aug 5, 2016
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
15 changes: 6 additions & 9 deletions BinaryEncoding.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -439,28 +439,25 @@ It is legal to have several entries with the same type.
| Name | Opcode | Immediates | Description |
| ---- | ---- | ---- | ---- |
| `unreachable` | `0x00` | | trap immediately |
| `block` | `0x01` | | begin a sequence of expressions, the last of which yields a value |
| `loop` | `0x02` | | begin a block which can also form control flow loops |
| `if` | `0x03` | | begin if expression |
| `block` | `0x01` | arity : `varuint1` | begin a sequence of expressions, yielding 0 or 1 values |
| `loop` | `0x02` | arity : `varuint1` | begin a block which can form control flow loops |
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

loop having an arity is awkward, because branches targeting a loop label are effectively required to have arity 0. A common validation strategy would record an arity of 0 in the control-flow stack entry for a loop, and then need to separately record the loop arity somewhere else.

Restricting loop to arity 0 would simplify it, and obviate its arity immediate. loops are less frequent than blocks, so the code size win from using loop's return value(s) directly are likely to be small, especially after accounting for the arity immediates it would add to every loop.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That's worth discussing, but should probably be a separate PR. Restricting the semantics of loops that way would be a design change, while this PR is only meant to change the binary encoding.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't understand: branches to a loop must have arity 0. A loop's arity can be entirely determined by the stack depth at fallthrough. @MikeHolman for the regalloc scheme you guys were talking about, is there any issue for loops in a multi-value setting? I'd assume not since there are no forward branches, so no join point.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@lukewagner The loop arity would describe loop's own return value, and not to branches to the loop top. This is non-obvious, so I created #742 to remove it.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I know, but my point is that, unlike branches where the end is a join from fallthrough and branches, the loop's end cannot be the target of branches, so it seems fine to simply define the arity as the stack depth at end.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Alternatively, I still like the symmetry of giving branch target immediates a direction bit; in that case the arity of loop would be meaningful in the same way as block.

| `if` | `0x03` | arity : `varuint1` | begin if expression |
| `else` | `0x04` | | begin else expression of if |
| `select` | `0x05` | | select one of two values based on condition |
| `br` | `0x06` | argument_count : `varuint1`, relative_depth : `varuint32` | break that targets an outer nested block |
| `br_if` | `0x07` | argument_count : `varuint1`, relative_depth : `varuint32` | conditional break that targets an outer nested block |
| `br` | `0x06` | relative_depth : `varuint32` | break that targets an outer nested block |
| `br_if` | `0x07` | relative_depth : `varuint32` | conditional break that targets an outer nested block |
| `br_table` | `0x08` | see below | branch table control flow construct |
| `return` | `0x09` | argument_count : `varuint1` | return zero or one value from this function |
| `drop` | `0x0b` | | ignore value |
| `nop` | `0x0a` | | no operation |
| `end` | `0x0f` | | end a block, loop, or if |

Note that there is no explicit `if_else` opcode, as the else clause is encoded with the `else` bytecode.

The counts following the break and return operators specify how many preceding operands are taken as transfer arguments; in the MVP, all these values must be either 0 or 1.
The _arities_ of `block`, `loop` and `if` operators specify how many values they leave on the operand stack; in the MVP, all arities must be either 0 or 1.

The `br_table` operator has an immediate operand which is encoded as follows:

| Field | Type | Description |
| ---- | ---- | ---- |
| arity | `varuint1` | number of arguments |
| target_count | `varuint32` | number of targets in the target_table |
| target_table | `uint32*` | target entries that indicate an outer block or loop to which to break |
| default_target | `uint32` | an outer block or loop to which to break in the default case |
Expand Down