Fork of https://github.com/WebAssembly/design/ with NanoWasm extensions. https://gitea.privatedns.org/xavi/nanowasm-design/atom?h=main 2018-05-04T16:47:20+00:00 2018-05-04T16:47:20+00:00 Romario Maxwell romario.maxwell@gmail.com 2018-05-04T16:47:20+00:00 urn:sha1:2614fd32d8d4a099fca021d1e880a9d9d8e848e8 All the modified URLs were checked to see if they are available over HTTPS by opening a new tab in the browser, entering the URL in the address bar, changing http:// to https:// and then verifying if the resource displayed is the same over HTTP and HTTPS for each URL. 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-11-01T06:26:34+00:00 Dmitri Shuralyov shurcooL@gmail.com 2016-11-01T06:26:34+00:00 urn:sha1:f1f8666b2dd8a75a35a605586517bf99157bd499 The Markdown parser used on the http://webassembly.org/ website doesn't support having a newline character between the [] and () parts of the Markdown link syntax. Remove that newline character in order for links to render properly on the website. 2016-10-30T16:22:33+00:00 Brad Nelson flagxor@gmail.com 2016-10-30T16:22:33+00:00 urn:sha1:18759dd1f259429504cba1b9470744f5135db7b4 2016-10-28T03:58:36+00:00 Brad Nelson flagxor@gmail.com 2016-10-28T03:58:36+00:00 urn:sha1:93e4e3b2d27884bf0cc989bed4f1161074804ada Added brief item on multiple return. 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 2016-07-12T04:34:03+00:00 Dominic Chen d.c.ddcc@gmail.com 2016-07-12T04:34:03+00:00 urn:sha1:62f30968a641ef6eb7f8cceadae232cea4ad7b4a This commit introduces a discussion of WebAssembly's security model for both users and developers, though primarily targeted at latter. Resolves #205. 2016-05-14T17:20:07+00:00 Kel humanoidanalog@gmail.com 2016-05-14T17:20:07+00:00 urn:sha1:76a4ae125ec2fcb7d5c767e4e600873f0d8380f0 2015-10-23T21:34:29+00:00 titzer titzer@google.com 2015-10-23T21:34:29+00:00 urn:sha1:f79cddcea94afb27127c8588e481f523e5b36e29 2015-10-15T15:22:07+00:00 Dan Gohman sunfish@mozilla.com 2015-09-14T20:14:53+00:00 urn:sha1:119d5b3125cd7e20d4ec43c069b234ae0ae9b0b9 The rationale for making C/C++ long double something other than 64-bit is: - there are use cases for quad-precision floating point types, and "long double" is a friendlier way to satisfy those use cases than extensions like "__float128" since "long double" has the benefit of libm and printf API support. - long double is a lost cause in terms of portable functionality anyway. 64-bit, 80-bit, and 128-bit long double types are in use in popular platforms, so people who want portable results aren't using it. - it's also a lost cause in terms of portable performance, as it's already significantly slower than double on several widely popular platforms, so people who want portable performance already have motivation to avoid it. The rationale for picking quad-precision over double-double is that even though double-double can be significantly faster, it has surprising numeric properties which make it undesirable to impose on unsuspecting code.