- From: JS Stats <info@jsstats.com>
- Date: Tue, 26 Jan 2016 11:23:34 +1100
- To: public-webassembly@w3.org
There is an initial binary encoding, the v8 experimental binary encoding, that is pending adoption, see https://github.com/WebAssembly/design/pull/520 Streaming support will be necessary to reduce latency - to allow the runtime to start compilation before the entire file is received. There is discussion about a layer that reorganizes the encoding for better compression, but it seems far to early to make any judgements. Running a dozen brotli decoders in parallel to uncompress separate component streams of the file might be a burden for a low end device. It seems well accepted that decoding will work on at least a function level granularity, so any encoding within a function seems possible so long as the AST is encoded without loss. There was even mention of a bottom-up encoding (sounds like a stack machine). I would hope it gives the same AST and semantics in either case, so could be transformed reversibly to a structure familiar to readers for presentation. There is discussion about a compression layer built above this. Brotli seems already accepted on the web, but it is not well optimized for the wasm binary format. I expect a dedicated prediction model with knowledge of the AST will do better. I did try to get a better source code story for WebAssembly but got little support. The group appears to be interested only in the 'compilation target' use case and can't see past the compilation or assembly metaphors. It appears possible to develop a more usable deployment source code independently so this seems the best and only practical approach. So I have forked off the development of a more usable deployment source code into a separate project, and if interested then please see https://github.com/wllang for some discussion of how this can be done and the limits. There is some initial code for importing and exporting wast, and decoding and encoding the binary. I think a lot more can be done here than people either appreciate or have any interest in working on. It is only one possible source code extension and perhaps could be a model for other projects. The Binary format is the real key to the success of the project - getting support across the browser vendors for it. Source code meta info does not affect this at all, nor even the wasm text format, and perhaps focusing on the critical binary-format and sideline everything else is a good strategy anyway. Regards Douglas Crosher On 01/26/2016 09:00 AM, Dennis E. Hamilton wrote: > Public work on WebAssembly is on the GitHub repository at <https://github.com/webassembly>. > > Look at the spec and design repositories for the direction of the work. It is still experimental and proof-of-concept at the level currently documented, it seems to me. The BinaryEncoding has some description at <https://github.com/WebAssembly/design/blob/master/BinaryEncoding.md>. > > The basic structure of WebAssembly, however it is encoded, is to carry an Abstract Syntax Tree (AST) which can also be written in a kind of LISP-like semi-functional form. This is a kind of functional form that is imperative and provides an eager evaluation model in which order of operation is predictable. > > An interesting aspect is working toward an initial MVP (Minimum Viable Product) release, <https://github.com/WebAssembly/design/blob/master/MVP.md>. (Tail recursion is not handled yet, for whatever that's worth.) > > An aid in this is a proof-of-concept implementation that translates to JavaScript and can also be used on systems where a native processor is not (yet) available. There are, in various states, translation of .NET IL to WebAssembly and also translation of WebAssembly to Java ByteCode. > > I also just noticed that, as for many assembly languages, attempting to translate back upwards to a human-usable higher-level source code will be tricky, especially since symbolic names are not necessarily preserved enough at the WebAssembly level. > > People can satisfy themselves how close this is to Java ByteCodes, Python byte coding, etc. > > - Dennis > >> -----Original Message----- >> From: Beyler, Jean Christophe [mailto:jean.christophe.beyler@intel.com] >> Sent: Monday, January 25, 2016 09:27 >> To: 'Rahman USTA' <rahman.usta.88@gmail.com>; public-webassembly@w3.org >> Subject: RE: WebAssembly and Bytecode question >> >> Dear Rahman, >> >> >> >> From what I’ve seen, the binary format is still not defined so what the >> final format will be is difficult to tell. >> >> >> >> However, from what discussions I have seen, it seems that there is >> interest in looking at a streaming + compression system so it won’t be >> instruction after instruction in binary format. But nothing is defined >> or set in stone yet, as far as I know :)
Received on Tuesday, 26 January 2016 00:24:09 UTC