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.

Sign up for GitHub

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

Edit high level goals based on recent discussions. #1

Closed
wants to merge 5 commits into from
Closed

Edit high level goals based on recent discussions. #1

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
5 commits
Select commit Hold shift + click to select a range
eb5cc04
Edit high level goals based on recent discussions.
jfbastien Apr 29, 2015
6ddd71c
Only fitting that my manager would find a typo in the work 'management'.
jfbastien Apr 30, 2015
c539673
Fold speed into the first point.
jfbastien Apr 30, 2015
db8c97d
Rework the programming languages bullet. I shortened from luke's sugg…
jfbastien Apr 30, 2015
e3cbf4b
Split upcoming features into its own file, and add to it. Add .gitign…
jfbastien Apr 30, 2015
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
1 change: 1 addition & 0 deletions .gitignore
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1 @@
*~
31 changes: 21 additions & 10 deletions HighLevelGoals.md
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -1,16 +1,27 @@
# WebAssembly High-Level Goals

1. Define a portable, size- and load-time-efficient binary format to serve as a web compilation target.
2. Define a human-editable text format that is isomorphic and convertible to/from the binary format.
3. Design v.1 to allow an effective (load-time and performance) [polyfill](https://github.com/WebAssembly/polyfill) via client-side compilation to [asm.js](http://asmjs.org).
4. Design v.1 as a Minimum Viable Product: basically what you can do with [asm.js](http://asmjs.org).
5. Design to integrate well with the existing web platform:
1. Define a portable, size- and load-time-efficient binary format to serve as a
web compilation target which can be compiled to execute at native speed and
take full advantage of a CPU's capabilities.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I wonder if "full advantage" won't set us up for criticism that we don't support My-Favorite-Obscure-ARM-op. We're inherently going to be making tradeoffs about what is common/useful which means not achieve 100%, but hopefully a very useful 75% that gets us 98% of native perf (pulling numbers out of thin air) on most workloads. How about "... at native speed by taking advantage of common hardware capabilities." which is perhaps even too conservative, but I'd rather over-deliver :)

2. Define a human-editable text format that is isomorphic and convertible
to/from the binary format.
3. Design to serve as a compilation target for a growing set of source languages
over time, starting with C/C++.
4. Design to maintain the versionless, feature-testing and backwards-compatible
evolution story of the web; engines should not need multiple, versioned
decoders.
5. Design and implement incrementally: the initial version will be a Minimum
Viable Product by being an effective [polyfill][] via client-side compilation
to [asm.js][], with a feature set similar to [asm.js][]'s current
features. Subsequent versions will be more [featureful][].
6. Design to integrate well with the existing web platform:
* execute in the same semantic universe as JavaScript;
* allow synchronous calls to and from JavaScript;
* enforce the same-origin security policy; and
* access browser functionality through the same Web APIs that are accessible to JavaScript.
6. Design to maintain the versionless, feature-testing and backwards-compatible evolution story
of the web; engines should not need multiple, versioned decoders.
* enforce the same-origin and permissions security policies; and
* access browser functionality through the same Web APIs that are accessible
to JavaScript.
7. Design to allow execution in non-browser environments.


[polyfill]: https://github.com/WebAssembly/polyfill
[asm.js]: http://asmjs.org
[featureful]: https://github.com/WebAssembly/spec/blob/master/UpcomingFeatures.md
22 changes: 22 additions & 0 deletions UpcomingFeatures.md
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,22 @@
# Upcoming Features
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for splitting out a separate file! "Upcoming Features" is a bit ambiguous to me (could mean "v.1" or not). How about "After-MVP Features"?

Second, within the list, I was thinking it'd be nice to segregate into things we expect to follow on with "real soon" after the MVP is out the door and the general list of things we're considering. My reasoning is that some of these things are kinda big and we probably won't get to for potentially quite a while (e.g., JIT support (speaking of, I actually think we can/need to do a lot more to support JIT than just dynamic compilation/linking, excited to talk about this in a separate thread)) and we don't want people to think this is just a grab bag; some things are really important and missing from the MVP so it'd be nice to convey this priority to stakeholders. My current thinking based on current feedback from asm.js users is that this list consists of: threads, SIMD, zero-cost EH, int64, restricted PTC (giving irreducible control flow).


Subsequent versions will expose further features which expand upon the
[high-level goals][], prioritized based on developer feedback, such as:
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think this list is actually expanding on a yet-to-be-created list of features in the MVP which would be in a separate file (with a lot more detail).


* Concurrency and parallelism through threads and SIMD.
* Dynamic loading.
* Platform-independent Just-in-Time compilation, potentially through dynamic
loading.
* Finer-grained control on memory management.
* Zero-cost exception handling.
* Stack unwinding.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe I don't understand by what you mean by "stack unwinding", but if you're saying "you should be able to get a programmatically and from the debugger get a stack trace", then I think that is actually v.1. E.g., Error.stack should include wasm frames and (though this wouldn't be in the spec) so should the devtools debugger/profiler.

* Garbage collection.
* Signal handling.
* Proper tail-calls.
* Irreducible control flow.
* Extra math which may not work the same on all platforms:
- Fused multiply-add.
- Reciprocal square-root approximate.
- 16-bit floating-point values.

[high-level goals]: https://github.com/WebAssembly/spec/blob/master/HighLevelGoals.md