diff options
| author | Brad Nelson <flagxor@gmail.com> | 2016-10-27 20:58:36 -0700 |
|---|---|---|
| committer | Seth Thompson <s3th.thompson@gmail.com> | 2016-10-27 20:58:36 -0700 |
| commit | 93e4e3b2d27884bf0cc989bed4f1161074804ada (patch) | |
| tree | 33fd57fb3056744ef198051a8a660afc4601178d /FeatureTest.md | |
| parent | cad0ea9ed5f0ac1dda62abe2c66d0a38ff8c104d (diff) | |
| download | nanowasm-design-93e4e3b2d27884bf0cc989bed4f1161074804ada.tar.gz | |
Tagging future features with icon. (#839)
Added brief item on multiple return.
Diffstat (limited to 'FeatureTest.md')
| -rw-r--r-- | FeatureTest.md | 19 |
1 files changed, 13 insertions, 6 deletions
diff --git a/FeatureTest.md b/FeatureTest.md index 14e3bad..5d53faa 100644 --- a/FeatureTest.md +++ b/FeatureTest.md @@ -2,8 +2,9 @@ See [rationale](Rationale.md#feature-testing---motivating-scenarios) for motivat # Feature Test -[PostMVP](PostMVP.md), applications will be able to query which features are -supported via [`has_feature` or a similar API](PostMVP.md#feature-testing). This +[PostMVP :unicorn:][future general], applications will be able to query which features are +supported via +[`has_feature` or a similar API :unicorn:][future feature testing]. This accounts for the pragmatic reality that features are shipped in different orders at different times by different engines. @@ -40,15 +41,15 @@ it can be constant-folded by WebAssembly engines. To illustrate, consider 4 examples: -* [`i32.min_s`](FutureFeatures.md#additional-integer-operators) - Strategy 2 +* [`i32.min_s` :unicorn:][future integer] - Strategy 2 could be used to translate `(i32.min_s lhs rhs)` into an equivalent expression that stores `lhs` and `rhs` in locals then uses `i32.lt_s` and `select`. -* [Threads](PostMVP.md#threads) - If an application uses `#ifdef` extensively +* [Threads :unicorn:][future threads] - If an application uses `#ifdef` extensively to produce thread-enabled/disabled builds, Strategy 1 would be appropriate. However, if the application was able to abstract use of threading to a few primitives, Strategy 2 could be used to patch in the right primitive implementation. -* [`mprotect`](FutureFeatures.md#finer-grained-control-over-memory) - If engines +* [`mprotect` :unicorn:][future memory control] - If engines aren't able to use OS signal handling to implement `mprotect` efficiently, `mprotect` may become a permanently optional feature. For uses of `mprotect` that are not necessary for correctness (but rather just catching bugs), @@ -96,5 +97,11 @@ polyfill would then replace `foo` with `foo_f64x2` if coarser granularity substitution. Since this is all in userspace, the strategy can evolve over time. -See also the [better feature testing support](FutureFeatures.md#better-feature-testing-support) +See also the [better feature testing support :unicorn:][future feature testing] future feature. + +[future general]: PostMVP.md +[future feature testing]: PostMVP.md#feature-testing +[future integer]: FutureFeatures.md#additional-integer-operators +[future thread]: PostMVP.md#threads +[future memory control]: FutureFeatures.md#finer-grained-control-over-memory |