- Where: zoom.us
- When: October 2, 4pm-5pm UTC (October 2, 9am-10am Pacific Time)
- Location: link on calendar invite
- Contact:
- Name: JF Bastien
- Email: jfbastien@apple.com
- Name: Ben Smith
- Email: binji@google.com
None required if you've attended before. Email JF Bastien or Ben Smith 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.
- The
ImportObjectis required forWebAssembly.instantiateStreamingand can be difficult to pass in some cases, see systemjs/systemjs#1757. - Funclets proposal (Dan Gohman)
- Poll: Accept for stage 0
- Consider renaming instructions containing slashes and colons. See WebAssembly/nontrapping-float-to-int-conversions#4 (comment)
- Discuss creation of a repository for a reference sysroot implementation for C and related languages. (Dan Gohman)
- Suggested name: https://github.com/WebAssembly/reference-sysroot
- "Sysroot" is a C-oriented term, and this will be a C-oriented repo (and languages that need similar support)
- Not everyone will need this. That's ok.
- Purposes:
- Provide a usable minimal execution environment for C and related things
- Define low-level interfaces to promote interoperability between different implementations
- Prepare for future syscall standardization discussions
- There is some positive discussion on an issue in the tool-conventions repo proposing a custom section that describes the producing toolchain. Is it worth specifying in the core spec's Custom Sections appendix (after the Name Section)?
- Closure
None
None
- Alex Crichton
- Adam Klein
- Andreas Rossberg
- Arun Purushan
- Ben Bouvier
- Ben Smith
- Ben Titzer
- Conrad Watt
- Dan Gohman
- David Piepgrass
- Deepti Gandluri
- Derek Schuff
- Francis McCabe
- Gordon Aplin
- Heejin Ahn
- Jacob Gravelle
- Jay Phelps
- Keith Miller
- Lars Hansen
- Limin Zhu
- Luke Wagner
- Michael Holman
- Mike Rourke
- Nick Fitzgerald
- Pat Hickey
- Peter Jensen
- Richard Winterton
- Sergey Rubanov
- Shiv Kushwaha
- Sven Sauleau
- Thomas Lively
- Tobin T
- Ulrik Sorber
- Yury Delendik
Lars to help (thanks!)
Jay seconds
The ImportObject is required for WebAssembly.instantiateStreaming and can be difficult to pass in some cases, see systemjs/systemjs#1757.
Skipped because Sven isn’t on the call.
Funclets proposal (Dan Gohman)
DG: proposal is on a github issue on the design repo, really just asking for stage 0 at this point, ie that committee is willing to consider it
DG: questions?
- Poll: Accept for stage 0
Unanimous Consent
AI(BS) Will create a new repo for this.
Consider renaming instructions containing slashes and colons. See WebAssembly/nontrapping-float-to-int-conversions#4 (comment) (Thomas Lively)
TL: As we’ve been implementing the assembler, running into issues with these characters. We have support in assembler thanks to Wouter for slashes. On GH issues we have consensus to remove colons from instruction names. They are only present in recently proposed instructions. Should we remove slashes from existing instructions as well. In conversion/float-to-int instructions. Shipped for quite a while. We have a workaround for slashes, but kind of ugly. Is it too late to change instruction names?
RW: There are 4 instructions, right?
JP: Is there any proposal for replacement of slash?
TL: Replacing with underscore, period. We need to bikeshed.
DG: There are about 25 instructions that use slash. That was the convention in MVP.
FM: Presumably will have a grace period.
TL/DS: We could accept both. There are a few tools, spec interpreter and wabt. What are we imposing on people outside those tools.
AR: There may be actual source code on the web. I would like to expand this for other names too. table.* and global.* If we want to, perhaps bikeshed offline.
LW: Q is: Are we open to a big text change?
BT: spec tests are text format and have to change, but wouldn't "break" per se
KM: Do we know of any tooling that will break on this?
JP: With the change of the memory instructions, made it difficult to update binaryen. Had to fix spec text changes before I could land my PR. We didn’t think about how it blocked other changes in a trickle down effect.
TL: The tools team could try to coordinate this.
BT: If we're going to do one renaming we should do it in one big step
BS: We should do this before we move the spec document to CR.
HA: Can we just change LLVM?
DS: We can, but it ends up being a bigger change to the assembler.
Poll: Should we consider making changes to the text format?
Unanimous consent
AI(TL): Turn this into an issue.
Discuss creation of a repository for a reference sysroot implementation for C and related languages. (Dan Gohman)
- Suggested name: https://github.com/WebAssembly/reference-sysroot
- "Sysroot" is a C-oriented term, and this will be a C-oriented repo (and languages that need similar support)
- Not everyone will need this. That's ok.
- Purposes:
- Provide a usable minimal execution environment for C and related things
- Define low-level interfaces to promote interoperability between different implementations
- Prepare for future syscall standardization discussions
DG: Coordinating low-level ABI details
DG: There are at least four ABIs out there
DG: Fix some type variability
DG: Fix Y2038 problems right now
DG: Want to expose common C interfaces we use across toolchains and libraries, for interoperation
DG: There are discussions at tc39 about builtin modules, functions that can be shared across JS implementations (node, browser), is there something here that we can share with wasm.
BT: I like this proposal, is it mostly to implement the C language standard.
DG: This is closer to what C calls a free-standing implementation. It’s the set of things that don’t need to do syscalls. I think it makes sense to include malloc, because we can use memory.grow. Will not be the be-all-end-all, because we will want different implementations of malloc for example.
BT: Do any of these require engine implementations?
DG: What we have currently, no. It’s the set of things that doesn’t require engine support. Memcpy, memset, compiler_rt for 128-bit math. Things that compilers will generate on their own. Stabilizing those things. Typedefs too, 2038 bug. Make sure that we use the same sizes for these things.
AR: This would define a kind of ABI. Why not make it a specification of some kind.
DG: It isn’t really in the core spec. I’m thinking in terms of a ref implementation. It would define the interfaces as an existence proof. If we want to right in doc that would be cool too.
BT: What about things like returning struct values?
DG: I think that would be good too. Clang has a set of conventions that are not controversial. For multi-value we may want to change.
BT: May want to coordinate with C API as well.
DG: I’m hoping to avoid the C++ ABI. Itanium shows that we can perhaps coordinate the ABI, but I’d like to skip that.
KM: How will that work with passing between host and the wasm module, for strings etc.
DG: We would have memcpy that implicitly copies in linear memory 0.
KM: Not defining interop between modules,
DG: No, just for toolchain coordination, just trying to avoid mutually incompatible libc implementations.
LW: Poll?
NF: (chat) Will this cover bit fields in the ABI?
DS: The C ABI should cover this.
FM: (chat) How is this different from host bindings for C?
DS: This is about wasm-to-wasm, not wasm-to-host.
DG: We could imagine defining something that would be host-bindings for C. This proposal would help for this.
BS: is it appropriate to have a new repo, or should this be in tool-conventions - who has an opinion?
DG: tool-conventions is all text, this is supposed to be code
DG: tool-conventions may be about the C compiler's ABI (enums, bitfields)
RW: If we were to do a host bindings for C, … [missed this]
DG: No imports, should be able to do with pure wasm.
NF: (chat) it is nice to have a new repo so if people are only interested in this they can unfollow the other issues.
POLL: Create a repo for this?
Unanimous consent
AI(BS): create a repo.
There is some positive discussion on an issue in the tool-conventions repo
proposing a custom section that describes the producing toolchain. Is it worth specifying in the core spec's Custom Sections appendix (after the Name Section)?
LW: would be nice to have a custom section that says what the originator of the code was, to allow us to measure in the wild (telemetry) what tools are being used etc
LW: If we want to do telemetry, we can expose the bit fields and not just a UA-string (which has privacy implications).
LW: step two is to give it a little bit of structure with some defined field, eg source language, coming from a github enum, say (field names, not field values necessarily)
LW: might be something about how the code was processed (bindgen, binaryen)
LW: etc
LW: open format so that there's space for custom parts and ad-hoc extensions
LW: if this is useful, would it go in the core spec appendix, along with the custom section?
JP: There have been some discussions about representing textual representation of custom sections. Seems like you may lose that info.
LW: You could make a text conversion for this. So you could grab the info from a GH markdown link.
JP: What about version numbers?
LW: The strings would be fixed thing, but you could have a version.
AR: I think this is useful in general. Only concern, there might be tools that depend on or differentiate on this information. There was an example in the discussion.
DG: GDB was mentioned where they sniff this and change behavior.
LW: If debuggers are a problem, then perhaps it belongs in that subcomittee. If it is somewhat standardized then people may depend on it.
AR: Maybe an argument for making it harder to process. [half joking]
LW: Engines can do whatever they want, but we could censor it.
TL: This is kind of a slippery slope; tools and versions, then you may want to add options they were called with.
LW: We already have this risk. Tool could mention custom section that has hot functions. If I was doing this for diagnostic, I may actually check for valid information so people wouldn’t try to sneak info in there.
TL: Do we need guidelines for how we consider features that require new custom section data? We want to unify our approach.
DS: Part of the reason for custom sections, is to allow people to do whatever they want with it.
LW: Still could be validated.
BT: BTW, about hot functions -- we will have an intern work on this this summer.
FM: (chat) we should follow a standard like that for exif and jpeg. Adding metadata to wasm presents many long term issues. Rather than doing this in an ad hoc way, we should try to follow a standard and/or best practice. Two examples to look at include EXIF and Dublin core. In addition, there are standard ways of representing version numbers.
BS: In general it sounds like we support, maybe just a question of how official.
AR: We may not want to put this in the core spec.
DS: Yes, perhaps put this in tools conventions.
DP: (chat) Minor thing: “I proposed a text format for WebAssembly which was rejected, though I never found out why.” It didn’t seem like there was much discussion about this.
BS: We ignored several text formats, a number of people were probably feeling that the text format was not all that crucial.
BT: We did discuss this some, but at the time it wasn’t as important to us as the binary format. We almost didn’t include it at all, but it was advocated that we really should have it.