Future-proof type opcodes #823

rossberg · 2016-10-19T14:39:42Z

Post MVP we will likely extend Wasm with a few richer types, e.g., function types for blocks, struct types, or function pointers. That introduces a number of places where types will be given either directly or via reference to the type section.

To make Wasm future-proof for efficiently overlaying both these spaces, this PR changes the existing type constructors to have negative opcodes, such that they are distinguishable from indexed type definitions (which are naturally positive).

For example, this will in the future allow

generalising block annotations to multiple or function types without requiring escape code hacks,
defining local variables that have struct type (by reference into the type section),
defining struct types whose fields are either value types, function (pointers), or other structs,
if desirable, inlining of function types for uses where currently a type section entry is required.

The PR also cleans up the description of type encodings.

titzer

This change generally LGTM, but I'm not sure we'll be able to swing this due to time constraints.

titzer · 2016-10-19T15:48:32Z

BinaryEncoding.md

 ### `value_type`
-A single-byte unsigned integer indicating a [value type](Semantics.md#types). These types are encoded as:
+A `varint7` indicating a [value type](Semantics.md#types). These types are encoded as:
 * `-0x01` indicating type `i32`


Note that this is byte value 0x7f?

rossberg · 2016-10-20T13:45:02Z

Online and offline comments addressed. Fixed out-of-bounds values.

lukewagner · 2016-10-20T14:04:04Z

BinaryEncoding.md

+
+| Field | Type | Description |
+| ----- | ---- | ----------- |
+| form | `varint32` | `-0x20` (i.e., the byte `0x60`) indicating a function type |


So in this negative constructor opcode space, we have -1, -2, -3, -4, -0x10, -0x20, -0x40. Do you think it makes sense to hoist these out into a new type_constructor subsection so that we can see them all in one list without having to know that these 7 values are all implicitly in the same index space? Then each of the 3 uses could specify which subset are valid.

Good idea, done.

titzer · 2016-10-20T14:07:10Z

BinaryEncoding.md

+
+### `block_type`
+A `varint7` indicating a signature. These types are encoded as:
+* `-0x40` (i.e., the byte `0x40`) indicating a signature with 0 results.


Sorry to bike-shed here, but do we want to start at -0x40, and then -0x3F for function and -0x3E for anyfunc.

Hm, by starting with the lowest absolute value we keep an open-ended gap at the "end" for future extension. The inverse order would become rather weird if we were to grow out of the 6 bit negative range of a varint7, because then we'd have to wrap around and add additional types or categories "before" the basic types.

titzer · 2016-10-20T14:51:32Z

On Thu, Oct 20, 2016 at 4:44 PM, rossberg-chromium <[email protected]

wrote:

@rossberg-chromium commented on this pull request.

In BinaryEncoding.md #823:

-### inline_signature_type
-A single-byte unsigned integer indicating a signature. These types are encoded as:
-* 0 indicating a signature with 0 results.
-* 1 indicating a signature with 1 result of type i32.
-* 2 indicating a signature with 1 result of type i64.
-* 3 indicating a signature with 1 result of type f32.
-* 4 indicating a signature with 1 result of type f64.
+A varint7 indicating a value type. These types are encoded as:
+* -0x01 (i.e., the byte 0x7f) indicating type i32
+* -0x02 (i.e., the byte 0x7e) indicating type i64
+* -0x03 (i.e., the byte 0x7d) indicating type f32
+* -0x04 (i.e., the byte 0x7c) indicating type f64
+
+### block_type
+A varint7 indicating a signature. These types are encoded as:
+* -0x40 (i.e., the byte 0x40) indicating a signature with 0 results.

Hm, by starting with the lowest absolute value we keep an open-ended gap
at the "end" for future extension. The inverse order would become rather
weird if we were to grow out of the 6 bit negative range of a varint7,
because then we'd have to wrap around and add additional types or
categories "before" the basic types.

Hmm. What about starting at -0x20 (-32) and counting towards negative
infinity also for constructors? I.e. -32 for void, -33 for function, -34
for anyfunc, etc.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
#823, or mute the thread
https://github.com/notifications/unsubscribe-auth/ALnq1KTe2cxdP0wTbQRIGfJ-TSmkouulks5q135bgaJpZM4KbDdk
.

lukewagner · 2016-10-20T15:59:49Z

lgtm; no strong opinion on @titzer's suggestion to pack 'em closer

rossberg · 2016-10-20T16:26:40Z

@titzer, the idea with the gaps is the same as for our instruction opcodes: there are different categories of types (currently, value types, element types, defined types), and it 's nice to leave space to extend each category.

titzer · 2016-10-21T08:49:41Z

lgtm

titzer · 2016-10-25T18:22:31Z

Alrighty

On Thu, Oct 20, 2016 at 6:27 PM, rossberg-chromium <[email protected]

wrote:

@titzer https://github.com/titzer, the idea with the gaps is the same
as for our instruction opcodes: there are different categories of types
(currently, value types, element types, defined types), and it 's nice to
leave space to extend each category.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#823 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/ALnq1JHJooocOrgTF9Hqvs1CGf5gZno7ks5q15ZbgaJpZM4KbDdk
.

* Reorganise opcode space (#826) * Future-proof type opcodes (#823) * Future-proof memory instructions (#824) * Fix order of copysign (#828) * Global types can be mutable, just not when imported (#830) * Naming nit: rename `flags` to `reserved` (#832) * Bump 0xd's version to 0xd * Make it hex

Make type opcodes negative; clean-up

f0f580e

rossberg added the binary format label Oct 19, 2016

rossberg added this to the MVP milestone Oct 19, 2016

rossberg changed the title ~~Make type opcodes negative~~ Future-proof type opcodes Oct 19, 2016

Fix type

0e8854a

titzer reviewed Oct 19, 2016

View reviewed changes

rossberg added 2 commits October 20, 2016 15:38

Fix out-of-range opcodes; make byte values explicit

f132a0d

Add a note

1f50feb

lukewagner reviewed Oct 20, 2016

View reviewed changes

titzer reviewed Oct 20, 2016

View reviewed changes

Define type constructor encodings in a single table

ed2ed39

Typo

17a6cac

rossberg merged commit d40f100 into binary_0xd Oct 21, 2016

rossberg deleted the overlay-tycons branch October 21, 2016 09:06

rossberg mentioned this pull request Oct 24, 2016

Binary updates for 0xD WebAssembly/spec#365

Merged

Future-proof type opcodes #823

Future-proof type opcodes #823

Uh oh!

Conversation

rossberg commented Oct 19, 2016

Uh oh!

titzer left a comment

Choose a reason for hiding this comment

Uh oh!

titzer Oct 19, 2016

Choose a reason for hiding this comment

Uh oh!

rossberg commented Oct 20, 2016

Uh oh!

lukewagner Oct 20, 2016 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

rossberg Oct 20, 2016

Choose a reason for hiding this comment

Uh oh!

titzer Oct 20, 2016

Choose a reason for hiding this comment

Uh oh!

rossberg Oct 20, 2016

Choose a reason for hiding this comment

Uh oh!

titzer commented Oct 20, 2016

@rossberg-chromium commented on this pull request.

Uh oh!

lukewagner commented Oct 20, 2016

Uh oh!

rossberg commented Oct 20, 2016

Uh oh!

titzer commented Oct 21, 2016

Uh oh!

titzer commented Oct 25, 2016

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

lukewagner Oct 20, 2016 •

edited

Loading