- Where: zoom.us
- When: August 4th, 4pm-5pm UTC (August 4th, 9am-10am Pacific Daylight Time)
- Location: link on calendar invite
None required if you've attended before. Send an email to the acting WebAssembly CG chair to sign up if it's your first time. The meeting is open to CG members only.
The meeting will be on a zoom.us video conference. Installation is required, see the calendar invite.
- Opening, welcome and roll call
- Opening of the meeting
- Introduction of attendees
- Find volunteers for note taking (acting chair to volunteer)
- Adoption of the agenda
- Proposals and discussions
- Review of action items from prior meeting.
- Poll: Should we allow non-normative updates to the v1 spec branch? (e.g. tests, clarifications) [5 min]
- Poll: Should we update the spec to use LEB128 encoding for prefixed opcodes? [10 min]
- The CG had a poll in May 2017 and decided to require prefix opcodes to be followed by a LEB128 opcode. However, the spec does not correctly reflect this, and some implementations differ in their behavior too.
- See WebAssembly/spec#1228
- Continuations & effect handlers as typed stacks (issue) (Daniel Hillerström, Daan Leijen, Sam Lindley, Matija Pretnar, Andreas Rossberg, KC Sivaramakrishnan) [20 min]
- Poll: Phase 1?
- A unifying view on stack-related mechanisms (Daniel Hillerström, Daan Leijen, Sam Lindley, Matija Pretnar, Andreas Rossberg, KC Sivaramakrishnan) [15 min]
- Lightly Typed WebAssembly [5-10 min]
- Closure
None
None
- Adam Klein
- Alex Crichton
- Alex Syrotenko
- Alon Zakai
- Alshamma
- Andreas Rossberg
- Andrew Brown
- Asumu Takikawa
- Benjamin Titzer
- Ben Smith
- Bill Budge
- Conrad Watt
- Daan Leijen
- Dan Gohman
- Daniel Hillerström
- Daniel Wirtz
- David Piepgrass
- Francis McCabe
- Heejin Ahn
- Ioanna Dimitriou
- Jacob Mischka
- Jakob Kummerow
- Jay Phelps
- Jlbirch
- JP Sugarbroad
- KC Sivaramakrishnan
- Keith Miller
- Lars Hansen
- Luke Imhoff
- Luke Wagner
- Matija Pretnar
- Nick Fitzgerald
- Paolo Severini
- Pat Hickey
- Peter Jensen
- Petr Penzin
- Rich Winterton
- Ross Tate
- Ryan Hunt
- Sabine
- Sam Lindley
- Sean Jensen-Grey
- Sergey Rubanov
- Sven Sauleau
- Thomas Lively
- Wouter Van Oortmersson
- Yury Delendik
- Zhi An Ng
Jay Phelps seconds
Poll: Should we allow non-normative updates to the v1 spec branch? (e.g. tests, clarifications) [5 min]
AR: Created the branch so we can do that, if we wanted to. I think it makes sense to fix typos and tests to that branch. Who does the work? Cherry pick from master makes sense.
LI: agree, more tests and bug fixes in the sense of missing tests or v1 implementation varies because of that, that’s good. Who does it? Up to people who care about v1, to back port changes that are non-breaking. Majority of us won’t be just supporting v1, up to them to support it. It might be that someone who cares enough about v1 becomes a maintainer of that branch.
BS: the details can be discussed on a GitHub issue, bigger qns is that whether we should do that, doesn’t look like much opposition. Do we have unanimous consent?
BS: we will allow this.
The CG had a poll in May 2017 and decided to require prefix opcodes to be followed by a LEB128 opcode. However, the spec does not correctly reflect this, and some implementations differ in their behavior too.
BS: spec document does not say that the opcode is leb128 encoded, but we had a CG poll in May 2017 for leb 128 encoding. Since we decided this many years ago, i think it should be a spec mistake. But since there are multiple different implementations, we might want to discuss this.
JP: who are the divergences?
BS: binaryen wabt prefix + leb, v8 does prefix + byte, SM does prefix + leb.
TL: no visible difference right now?
BS: nope, long encoding
AR: extension operators and bulk operators
BS: bulk is not upstream yet, non-trapping. You can write those as a long encoding, that will diverge implementation.
AR: right now it is conservative, we won’t break anything if we allow LEB.
TL: i think we should make the change
BS: agree, any opposition?
AR: this is something we screwed up in proposals
AR: we could interpret this differently, for now we allow single byte LEB, but if we need more codespace, then 2 byte leb.
BS: danger there is that implementation have to care about that. Currently implementations already have to read LEB, it will be nicer to have uniformity.
KM: right now SIMD already have more, you have to support LEB if you have to support SIMD
BS: if you have a generic mechanism for opcode, if you read a prefix byte, you always LEB.
AR: rephrase: must be a LEB but no redundant bytes.
BS: you could do that, but that doesn't exist in the spec currently
JS: opcode encodings be canonical -> faster decoding
LH: decoding is slower since there is more check to do
KM: if you know everything is 127 or less then assert
LH: if you open code everything, but you prefer 1 reader for a opcode
KM: templated leb decoder that has max size and does it for you
TL: this doesn’t need to be complicated, make it LEB, call it a day
KM: also agree, we expect these not to be the common instructions, if they are slower by 1 or 2 instructions, not too bad
BS: sounds like not really opposition... Okay let’s say unanimous consent to make this change, to update to LEB128 to opcode? ... Okay, we can follow up on the issue.
Continuations & effect handlers as typed stacks (issue) (Daniel Hillerström, Daan Leijen, Sam Lindley, Matija Pretnar, Andreas Rossberg, KC Sivaramakrishnan) [20 min]
Effect handler proposal SLIDES