Repository navigation
How to track implementation status? #21
Description
Reading over the proposals the phase tags are a great way to get a high-level idea about where a proposal is in the process, but one thing I've found that's somewhat difficult to figure out is the actual concrete implementation status. While the phases imply some degree of implementation, I've found it also nice to know the concrete status in various engines.
For example, SIMD is implemented Node, but it disagrees with LLVM's opcode definitions. Bulk memory operations have recently been implemented in Firefox, but are currently temporarily diverged from the spec in terms of encoding. Atomic instructions and SharedArrayBuffer seem to be implemented in a lot of places!
Would it be possible to have a section either on each proposal itself (in the proposal repository) or in this tracking repository (via the issues or the README) to have a location to edit about the current status? This may also be a bit of a pipe dream because these sorts of statuses are notoriously hard to keep up to date.
This is largely motivated from a desire to test out reference types especially because it's in phase 3 which seems much farther along than many other proposals! At the outset though I don't actually know where I could test it (Firefox? Node? Chome? Safari?) and I'll be digging into various engines to see implementation statuses. For example I know Firefox doesn't support anyref tables right now, but that was learned through other means!
Do others feel like it's possible to do this? I'd also be fine ruling this under "there's so few people this'd apply to it's not worth the effort", as that seems totally reasonable to me!
Activity
binji commentedon Oct 17, 2018
I think this would be useful if it were accurate, but I think it may be too hard to maintain as documentation, especially if you want specific information as you mentioned above. That said, I can imagine someone making something like https://wpt.fyi or https://kangax.github.io/compat-table/es6/ using tests from proposals (or writing their own), though that would be a lot of work to maintain too.
Not saying we should give up, though! Maybe it's enough to ask champions occasionally to give updates on implementation status, and try to provide high-level updates on the proposal repos. In addition, if other folks want to dig in and track the info down, I'd encourage submitting PRs with that info.
Perhaps something like:
--experimental-froblukewagner commentedon Oct 17, 2018
Something automated would be neat, but also hard to automatically capture the "behind
--experimental-frob" state. What about just adding a new (wide) column that different wasm consumers could self-fill-in?chicoxyzzy commentedon Oct 17, 2018
This could be even harder if we want to test not just browser engines but also other environments.
alexcrichton commentedon Oct 18, 2018
Ah @binji that sounds like a great idea! I think another way to phrase this is "I'd recently learned about the implementation state of a few proposals but didn't see it written down, and I was curious if there was a location I could write it down too". I think this could definitely be solved with a contributor-driven section which perhaps has some qualifying text above it about how it may be out of date.
I'd also imagine that this could be relatively free-form in the sense that it wouldn't want to be too strict about format (like @lukewagner I can't imagine this being automatically populated).
chicoxyzzy commentedon Oct 19, 2018
Probably we can use eshost to test JS engines and collect some data. I'll try to build a prototype when I'll have some free time.
chicoxyzzy commentedon Nov 8, 2018
Nice project by Bocoup: https://test262.report. Unfortunately it doesn't cover
WebAssemblybuilt-in Object.Horcrux7 commentedon Dec 31, 2018
The following table shows the status of future WebAssembly features required by JWebAssembly in nightly builds in various implementations according to my tests.
To use it also some flags and switches are needed.
petamoriken commentedon Apr 21, 2019
xtuc/webassembly-feature helps to confirm the implementation of the ready environment.
chicoxyzzy commentedon Apr 21, 2019
Wasm needs feature testing at some point
KronicDeth commentedon Apr 21, 2019
Has anyone brought up support for fat modules with thunks that are rewritten to the supported version once the feature is detected or not? This would be similar to game engines detecting GPU or SSE extensions once on boot and then hard coding the jump there after. The spec itself would have to support the jump table rewrite on feature detect since general code writing is disallowed for security.
chicoxyzzy commentedon Apr 21, 2019
@KronicDeth if I understand you correctly, "jump" is possible already via
call_indirect. WebAssembly still lacks feature detection though. I think that something like( has_feature "simd" )along withi32.eq/i32.eqzandcall_indirectmight work.lars-t-hansen commentedon Apr 22, 2019
Since feature detection (for most features anyway) is currently only possible from the host environment (via validation and selective module instantiation) and one thereafter has to do an intermodule indirect call to the dynamically selected module to use the feature or the polyfill, dynamically selected features have a bit of overhead both for setup and use.
But there's been pretty broad agreement so far that there is no "simd" feature in wasm; implementations are in principle free to support subsets of a proposal and of course post-mvp some implementations may support the mvp and some may support more than that. Additionally, there will be bugs to work around, so there may be a time when polyfilling one operation of a proposal will be attractive. IMO we'd be better off making sure indirect calls are very fast (once we have proper function types this will get a little better) and perhaps finding ways to express the module selection logic into wasm to decouple it from the host, when possible.
binji commentedon Apr 22, 2019
We've discussed a number of times providing some kind of "validation failure boundary", where functions can optionally fail validation, and if they do, will be replaced by
unreachable. Then an instruction can be added to query whether that validation succeeded. That said, even this functionality wouldn't work w/ things like SIMD, which requires changes to the type section too. But I think there's potentially a nice solution here -- we just need more design work.