Add a proposal to BinaryEncoding.md #496
Conversation
|
I've filed issue #497 to track the discussion of this proposal. |
|
Concerns: Iterating on a Google Doc is a very asymmetric process, it differs from the Github PR-based process we've used for the rest of this project, has lower transparency, and an unclear relationship to the W3C community group process. While I agree that the format is a good starting point (and there is much work to be done), we should give it a new name which reflects its shared nature. |
|
Should I create a new markdown with similar contents on GitHub? |
|
The current file is not accessible to me so probably not the general public. Perhaps it belongs with the v8-native-prototype for now. |
|
You can find the public link at the corresponding issue: https://docs.google.com/document/d/1-G11CnMA0My20KI9D7dBR6ZCPOBCRD0oCH6SHCPFGx0/edit |
|
@titzer Yes, that sounds good to me. If you think there are advantages to a different workflow, I'm open to such ideas too. |
|
Cool, can you guys explain what you have in mind with: Can modules This comes back to my concern about the binary format, feel like its going to be very system specific. |
|
@ncbray ^^^ |
|
@jbondc - I am not entirely sure what you're asking, but I suspect it's orthogonal to this PR? To give some background information... All the wassembler stuff is experimental. The original goal was to generate an input for the V8 backend. End-to-end from LLVM to V8 is now starting to work, so I've been focusing on that for the moment: https://github.com/WebAssembly/wasm-e2e system.wasm was touching on the idea that there needs to be functionality provided by the system - syscall opcodes, FFI provided by the system, whatever - it can be rationalized a number of different ways. For the wassembler, it was implemented as a mixture of FFI outcalls that were automatically provided by the system, functions that were turned into opcodes (sqrt), and code that got compiled into the binary (similar to libc, in a way). For example, when threading is supported, a function or opcode to create threads will need to be added. system.wasm is just "whatever worked" for getting the functionality I needed from the system. The threading stuff was experimenting with polyfilling threaded WASM to JS with shared array buffers. It's going to be a while before the native backends support threading, but Chrome and Firefox now have shared array buffer prototypes. So prototyping threading via polyfill is easier, ironically. Conceptually, "threading" in this case means there will be multiple threads using the same code and accessing the same memory - talking to each other via memory, atomics, and futexes. How one WASM binary talks to another WASM binary (or JS, or directly to the system) is a related issue that is complicated by threading, and that's the question I was eventually hoping to explore with the prototype. |
|
Experimentation is good. I've found this paper useful to think about concurrency:
I'll try to come up with more concrete questions and ask them in #104 . |
|
I'm just going to merge this PR with the hope of revising the document in place in future work. |
Add a proposal to BinaryEncoding.md
I've written a design document detailing the prototype binary format built for V8. It is meant as a starting point for discussion. It is complete as far as the design repository up to today (Dec 8, 2015). It has several enhancements and refactorings possible, most of which are noted in the document linked here (https://docs.google.com/a/google.com/document/d/1761v1AfhFM5kE8NArF_PyXcl-iVh0Dx3InOrmcyIoiI/pub).
We intend to keep iterating on the design and I will file an issue to track discussions there.
Apologies if permissions on the document are not properly set for the entire audience. It is intended to be public, so please ping me or the issue if it is not accessible.