Fork of https://github.com/WebAssembly/design/ with NanoWasm extensions. https://gitea.privatedns.org/xavi/nanowasm-design/atom?h=main 2017-11-15T16:48:14+00:00 2017-11-15T16:48:14+00:00 Joseph Richey joerichey@google.com 2017-11-15T16:48:14+00:00 urn:sha1:e2be77eaac770268a4c22fb09c6f648de7b9b6b8 This link standardizes how all the other design pages will refer to future features (either in `FutureFeatures.md` or in a tracking issue). All links to these upcoming features now use references at the bottom of the doc page (as opposed to inline links or references). Note that this change makes it very easy for the doc links to be updated when a tracking issue is started. As all the references have a standard format; a simple find/replace script will get everything. This commit also makes sure that references now point to a tracking issue if one exists. Note that this means a future CL can now delete some of the unnecessary sections from `FutureFeatures.md`. The only visible change from this commit is that certain broken links are now fixed, or links pointing to a doc section now point to the correct tracking issue. 2016-10-11T15:47:02+00:00 titzer titzer@google.com 2016-10-11T15:47:02+00:00 urn:sha1:e49fc18b684c953e3d920dcfc4bfce8ede9268dd * Rename AstSemantics.md to Semantics.md * Rewrite Semantics for structured stack machine * Update control instructions * Update nop * More tweaks * Update README.md * Update Semantics.md * Update Semantics.md * Address @rossberg-chromium comments 2015-11-02T23:32:56+00:00 Brett Cannon brettcannon@users.noreply.github.com 2015-11-02T23:32:56+00:00 urn:sha1:557516e9dfcb60c41aa252caedfb015679a75254 The docs for importing is no longer in MVP.md but in Modules.md now. 2015-10-23T21:11:04+00:00 titzer titzer@google.com 2015-10-23T21:11:04+00:00 urn:sha1:76e43e93df7b37d410c95938c04cb7f8e4898b62 2015-09-05T18:35:16+00:00 Dan Gohman sunfish@mozilla.com 2015-09-05T18:29:49+00:00 urn:sha1:c455c03a6aeac6b2300c928a0d5adf0d86b2bb5b According to clang, all common 64-bit CPUs, x86-64, arm64, mips64, ppc64, sparcv9, and systemz (and bpf, if that counts) support a 64-bit integer type as "lock free". In the spirit of #327, this is a significant agreement among 64-bit architectures, but not 32-bit architectures. I propose we think about the >4GiB linear memory feature as belonging to a distinct "architecture" called *wasm64*, when we need to distinguish it from *wasm32*. This will allow us to say that wasm64 has up to 64-bit lock-free integers, while wasm32 only has up to 32-bit lock-free integers. If we add signal handling it could also let us say that wasm64 has up to 64-bit signal-atomic integers (sig_atomic_t). It would also make it obvious what types to use around page_size and resize_memory. Except where it makes sense to make them different, wasm32 and wasm64 would otherwise be kept identical. In particular, wasm32 would still have 64-bit integers. The main negative consequence of this distinction is that wasm64 code would not be supported on many popular 32-bit CPUs. This is unfortunate, but it would already be the case that code using 64-bit pointers wouldn't run as efficiently as code using 32-bit pointers on 32-bit platforms. There's a desire to leave open the possibility of having both 32-bit and 64-bit linear memory addressing within a single instance. wasm64 could still be made to support mixing 64-bit indices and 32-bit indices if we choose, for example. We could potentially even permit wasm32 libraries to be linked into wasm64 applications (though there would of course be ABI complications at the C/C++ level, non-C/C++ code might be able to take advantage of this). 2015-09-02T23:38:07+00:00 JF Bastien github@jfbastien.com 2015-09-02T23:38:07+00:00 urn:sha1:8928237836149733e14848326c3afdf293787e1f 2015-09-02T20:22:35+00:00 JF Bastien github@jfbastien.com 2015-09-02T20:22:35+00:00 urn:sha1:cd8df8f991589c1dec9abc71304ccde30d74264c Addresses #300. 2015-08-27T18:59:52+00:00 Dan Gohman sunfish@mozilla.com 2015-08-27T18:59:52+00:00 urn:sha1:e6f309667265cb0457f90ec74fc958caf57993f8 IEEE 754-2008 contains several useful improvements over IEEE 754-1985. And should there be a future IEEE 754 document, we can update the references at the time that we make any necessary semantic changes. 2015-08-26T21:18:13+00:00 Derek Schuff dschuff@chromium.org 2015-08-26T21:09:25+00:00 urn:sha1:a148746c073dd1c4b00d2387f2b77743d6c27004 2015-07-07T00:27:37+00:00 Dan Gohman sunfish@mozilla.com 2015-07-07T00:27:37+00:00 urn:sha1:603f84c21795de1cc516a690efa781d9b3c2f2c2