Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

How to track implementation status? #21

Open
alexcrichton opened this issue Oct 17, 2018 · 13 comments

Comments

Projects
None yet
8 participants
@alexcrichton
Copy link

commented Oct 17, 2018

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!

@binji

This comment has been minimized.

Copy link
Member

commented 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:

Engine/Tool Status
v8 implementation behind flag --experimental-frob
wabt implemented, no interpreter support
@lukewagner

This comment has been minimized.

Copy link
Member

commented 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

This comment has been minimized.

Copy link
Collaborator

commented Oct 17, 2018

This could be even harder if we want to test not just browser engines but also other environments.

@alexcrichton

This comment has been minimized.

Copy link
Author

commented 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

This comment has been minimized.

Copy link
Collaborator

commented 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

This comment has been minimized.

Copy link
Collaborator

commented Nov 8, 2018

Nice project by Bocoup: https://test262.report. Unfortunately it doesn't cover WebAssembly built-in Object.

@Horcrux7

This comment has been minimized.

Copy link

commented 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.

Feature V8 SpiderMonkey WABT
floar-to-int yes yes yes
Sign-extension yes yes yes
Multi-value yes - yes
Reference Types yes yes -
Garbage collection - partly -
Exceptions partly - partly

To use it also some flags and switches are needed.

@petamoriken

This comment has been minimized.

Copy link

commented Apr 21, 2019

xtuc/webassembly-feature helps to confirm the implementation of the ready environment.

@chicoxyzzy

This comment has been minimized.

Copy link
Collaborator

commented Apr 21, 2019

Wasm needs feature testing at some point

@KronicDeth

This comment has been minimized.

Copy link
Contributor

commented 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

This comment has been minimized.

Copy link
Collaborator

commented 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 with i32.eq / i32.eqz and call_indirect might work.

@lars-t-hansen

This comment has been minimized.

Copy link

commented 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

This comment has been minimized.

Copy link
Member

commented 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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.