Remove more references to AST #806

titzer · 2016-09-22T12:05:43Z

This PR updates several documents to replace the discussion of ASTs with discussion of the structured stack machine design of 0xC.

This is about 1/3rd of the documentation work necessary to bring the design repository up to date. Splitting this up is an attempt to organize the changes into reviewable chunks. For example, this PR didn't touch AstSemantics, BinaryEncoding, or a few other places that refer to "initializer expressions."

Remove a reference to AST in JS.md. Note that the ml-proto spec still uses the name `Ast.Module` and has files named `ast.ml`, etc, so leaving those references intact for now.

lukewagner

generally lgtm with a few nits

lukewagner · 2016-09-22T22:55:29Z

Rationale.md

+
+* We started with an AST and generalized to a [structured stack machine](AstSemantics.md). ASTs allow a 
+  dense encoding and efficient decoding, compilation, and interpretation.
+  The stack machine is a generalization of ASTs allowed in previous versions while allowing


Maybe good to specify "The structured stack machine of WebAssembly is a ...".

lukewagner · 2016-09-22T22:57:37Z

Rationale.md

-
+The WebAssembly stack machine is restricted to structured control flow and structured
+use of the stack. This greatly simplifies one-pass verification, avoiding a fixpoint computation
+like that of other stack machines such as the Java Virtual Machine.


Perhaps append "Java Virtual Machine (in the absence of stack maps)" (linking to some description of stack maps).

Is it worth noting here that we are likely to apply some moderate generalisations post-MVP (e.g. multiple values)?

lukewagner · 2016-09-22T22:59:33Z

Rationale.md

+  efficiency gains in interpretation and baseline compilation, as well as a straightforward 
+  design for multi-return functions.
+* The stack machine allows smaller binary encoding than registers or SSA, and structured control
+  flow preserves the size advantages of an AST: [JSZap][], [Slim Binaries][].


I can imagine encodings of basic-blocks+goto that would be roughly the same size as what we have with blocks and branches. I think the better argument is that structured control flow simplifies validation, SSA construction, and various other compiler-backend algorithms.

rossberg · 2016-09-23T02:17:14Z

MVP.md

 * The WebAssembly binary format, which is designed to be natively decoded by 
  WebAssembly implementations, is specified as a 
-  [binary serialization](BinaryEncoding.md) of a module's AST.
+  [binary encoding](BinaryEncoding.md) of the module's instructions.


This formulation is a bit weird, given that a module contains much more than just instructions. How about "a module's structure and the contained instructions"?

rossberg · 2016-09-23T02:17:35Z

MVP.md

 * The WebAssembly text format, which is designed to be read and written when
  using tools (e.g., assemblers, debuggers, profilers), is specified as a
-  [textual projection](TextFormat.md) of a module's AST.
+  [textual projection](TextFormat.md) of a module's instructions.


Similarly here.

rossberg · 2016-09-23T02:21:58Z

Rationale.md

+WebAssembly producers, e.g. in compiling expression languages. It offers significant 
+size reduction by avoiding the need for `set_local`/`get_local` pairs in the common case 
+of an expression with only one immediate use. Control flow instructions can then model
+expressions with result values, thus allowing even more opportunities to further reduce


Perhaps also mention that branches with (especially multiple) arguments can model phis?

rossberg · 2016-09-23T02:26:00Z

Rationale.md

-
+The WebAssembly stack machine is restricted to structured control flow and structured
+use of the stack. This greatly simplifies one-pass verification, avoiding a fixpoint computation
+like that of other stack machines such as the Java Virtual Machine.


Is it worth noting here that we are likely to apply some moderate generalisations post-MVP (e.g. multiple values)?

titzer · 2016-09-23T09:21:06Z

Addressed review comments. PTAL.

lukewagner · 2016-09-23T13:57:32Z

Thanks, lgtm

* Clarify that wasm may be viewed as either an AST or a stack machine. (#686) * Clarify that wasm may be viewed as either an AST or a stack machine. * Reword the introductory paragraph. * Add parens, remove "typed". * Make opcode 0x00 `unreachable`. (#684) Make opcode 0x00 `unreachable`, and move `nop` to a non-zero opcode. All-zeros is one of the more common patterns of corrupted data. This change makes it more likely that code that is accidentally zeroed, in whole or in part, will be noticed when executed rather than silently running through a nop slide. Obviously, this doesn't matter when an opcode table is present, but if there is a default opcode table, it would presumably use the opcodes defined here. * BinaryEncoding.md changes implied by #682 * Fix thinko in import section * Rename definition_kind to external_kind for precision * Rename resizable_definition to resizable_limits * Add opcode delimiter to init_expr * Add Elem section to ToC and move it before Data section to reflect Table going before Memory * Add missing init_expr to global variables and undo the grouped representation of globals * Note that only immutable globals can be exported * Change the other 'mutability' flag to 'varuint1' * Give 'anyfunc' its own opcode * Add note about immutable global import requirement * Remove explicit 'default' flag; make memory/table default by default * Change (get|set)_global opcodes * Add end opcode to functions * Use section codes instead of section names (rebasing onto 0xC instead of master) This PR proposes uses section codes for known sections, which is more compact and easier to check in a decoder. It allows for user-defined sections that have string names to be encoded in the same manner as before. The scheme of using negative numbers proposed here also has the advantage of allowing a single decoder to accept the old (0xB) format and the new (0xC) format for the time being. * Use LEB for br_table (#738) * Describe operand order of call_indirect (#758) * Remove arities from call/return (#748) * Limit varint sizes in Binary Encoding. (#764) * Global section (#771) global-variable was a broken anchor and the type of count was an undefined reference and inconsistent with all the rest of the sections. * Make name section a user-string section. * Update BinaryEncoding.md * Update BinaryEncoding.md * Use positive section code byte * Remove specification of name strings for unknown sections * Update BinaryEncoding.md * Remove repetition in definition of var(u)int types (#768) * Fix typo (#781) * Move the element section before the code section (#779) * Binary format identifier is out of date (#785) * Update BinaryEncoding.md to reflect the ml-proto encoding of the memory and table sections. (#800) * Add string back * Block signatures (#765) * Replace branch arities with block and if signatures. Moving arities to blocks has the nice property of giving implementations useful information up front, however some anticipated uses of this information would really want to know the types up front too. This patch proposes replacing block arities with function signature indices, which would provide full type information about a block up front. * Remove the arity operand from br_table too. * Remove mentions of "arguments". * Make string part of the payload * Remove references to post-order AST in BinaryEncoding.md (#801) * Simplify loop by removing its exit label. This removes loop's bottom label. * Move description of `return` to correct column (#804) * type correction and missing close quote (#805) * Remove more references to AST (#806) * Remove reference to AST in JS.md Remove a reference to AST in JS.md. Note that the ml-proto spec still uses the name `Ast.Module` and has files named `ast.ml`, etc, so leaving those references intact for now. * Use "instruction" instead of "AST operator" * Update rationale for stack machine * Update Rationale.md * Update discussion of expression trees * Update MVP.md * Update Rationale.md * Update Rationale.md * Remove references to expressions * Update Rationale.md * Update Rationale.md * Address review comments * Address review comments * Address review comments * Delete h

titzer added 11 commits September 22, 2016 11:13

Remove reference to AST in JS.md

04bb14f

Remove a reference to AST in JS.md. Note that the ml-proto spec still uses the name `Ast.Module` and has files named `ast.ml`, etc, so leaving those references intact for now.

Use "instruction" instead of "AST operator"

d2ae37a

Update rationale for stack machine

d518661

Update Rationale.md

b92cb8d

Update discussion of expression trees

3eed357

Update MVP.md

51d502a

Update Rationale.md

315b6d7

Update Rationale.md

464fe0b

Remove references to expressions

fad3c17

Update Rationale.md

1201fa8

Update Rationale.md

67a2253

lukewagner reviewed Sep 22, 2016

View reviewed changes

rossberg reviewed Sep 23, 2016

View reviewed changes

titzer added 3 commits September 23, 2016 11:16

Address review comments

6b0f4d7

Address review comments

19ade4b

Address review comments

0a3c03c

titzer merged commit 1e505de into binary_0xc Sep 28, 2016

titzer deleted the binary_0xc_ast_text branch September 28, 2016 15:14

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Remove more references to AST #806

Remove more references to AST #806

titzer commented Sep 22, 2016

lukewagner left a comment

lukewagner Sep 22, 2016

lukewagner Sep 22, 2016 •

edited

Loading

rossberg Sep 23, 2016

lukewagner Sep 22, 2016 •

edited

Loading

rossberg Sep 23, 2016 •

edited

Loading

rossberg Sep 23, 2016

rossberg Sep 23, 2016 •

edited

Loading

rossberg Sep 23, 2016

titzer commented Sep 23, 2016

lukewagner commented Sep 23, 2016

Remove more references to AST #806

Remove more references to AST #806

Conversation

titzer commented Sep 22, 2016

lukewagner left a comment

Choose a reason for hiding this comment

lukewagner Sep 22, 2016

Choose a reason for hiding this comment

lukewagner Sep 22, 2016 • edited Loading

Choose a reason for hiding this comment

rossberg Sep 23, 2016

Choose a reason for hiding this comment

lukewagner Sep 22, 2016 • edited Loading

Choose a reason for hiding this comment

rossberg Sep 23, 2016 • edited Loading

Choose a reason for hiding this comment

rossberg Sep 23, 2016

Choose a reason for hiding this comment

rossberg Sep 23, 2016 • edited Loading

Choose a reason for hiding this comment

rossberg Sep 23, 2016

Choose a reason for hiding this comment

titzer commented Sep 23, 2016

lukewagner commented Sep 23, 2016

lukewagner Sep 22, 2016 •

edited

Loading

lukewagner Sep 22, 2016 •

edited

Loading

rossberg Sep 23, 2016 •

edited

Loading

rossberg Sep 23, 2016 •

edited

Loading