diff options
| author | titzer <titzer@google.com> | 2016-10-11 17:47:02 +0200 |
|---|---|---|
| committer | GitHub <noreply@github.com> | 2016-10-11 17:47:02 +0200 |
| commit | e49fc18b684c953e3d920dcfc4bfce8ede9268dd (patch) | |
| tree | db3843485e77013c763c4dbf27de9ab3711e371b /CAndC++.md | |
| parent | acfa2e2f6e02bb4f9c46a03882b72fb43e410eca (diff) | |
| download | nanowasm-design-e49fc18b684c953e3d920dcfc4bfce8ede9268dd.tar.gz | |
Structured stack (#813)
* 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
Diffstat (limited to 'CAndC++.md')
| -rw-r--r-- | CAndC++.md | 4 |
1 files changed, 2 insertions, 2 deletions
@@ -88,7 +88,7 @@ optimizers still assume that undefined behavior won't occur, so such bugs can still lead to surprising behavior. For example, while unaligned memory access is -[fully defined](AstSemantics.md#alignment) in WebAssembly, C and C++ compilers +[fully defined](Semantics.md#alignment) in WebAssembly, C and C++ compilers make no guarantee that a (non-packed) unaligned memory access at the source level is harmlessly translated into an unaligned memory access in WebAssembly. And in practice, popular C and C++ compilers do optimize on the assumption that @@ -116,7 +116,7 @@ rather than on the underlying platform. For those details that are dependent on the platform, on WebAssembly they follow naturally from having 8-bit bytes, 32-bit and 64-bit two's complement integers, and [32-bit and 64-bit IEEE-754-2008-style floating point support] -(AstSemantics.md#floating-point-operators). +(Semantics.md#floating-point-operators). ## Portability of compiled code |
