| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
|
| |
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.
|
| | |
|
| |
|
| |
Added brief item on multiple return.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
* 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
|
| |
|
|
|
| |
This commit introduces a discussion of WebAssembly's security model
for both users and developers, though primarily targeted at latter.
Resolves #205.
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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).
|
| |
|
|
|
|
| |
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.
|
| | |
|
| | |
|
| | |
|
| |\
| |
| | |
Move the note about C/C++ undefined behavior into CAndC++.md.
|
| | |
| |
| |
| | |
The text fits better there, and this also tidies up Nondeterminism.md.
|
| |\ \
| | |
| | | |
Add a note a about C and C++ language support.
|
| | | | |
|
| | |/ |
|
| |/ |
|
| | |
|
| | |
|
| | |
|
| |
|
