From 3cd3dde7eb1b90abfcfa9b100ca6afd09237a12e Mon Sep 17 00:00:00 2001 From: Dan Gohman Date: Wed, 3 Jun 2015 12:16:54 -0700 Subject: Rename "V1" aka "v.1" to "MVP". --- BinaryEncoding.md | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-) (limited to 'BinaryEncoding.md') diff --git a/BinaryEncoding.md b/BinaryEncoding.md index c801ae5..a01f423 100644 --- a/BinaryEncoding.md +++ b/BinaryEncoding.md @@ -1,14 +1,14 @@ # Binary Encoding This document describes the binary encoding of the AST nodes defined in the [AST semantics](AstSemantics.md). -For the context of this document, see the [Binary format](V1.md#binary-format) section of the [v.1 doc](V1.md). +For the context of this document, see the [Binary format](MVP.md#binary-format) section of the [MVP doc](MVP.md). The binary encoding is designed to allow fast startup, which includes reducing download size and allow for quick decoding. Considering the matter of reducing download size, we can see it as having three layers: * The **raw** binary encoding itself, natively decoded by the browser, and to be standardized in - v.1 of the spec. + the MVP of the spec. * **Specific** compression to the binary encoding, that is unreasonable to expect a generic compression algorithm like gzip to achieve. * This is not meant to be standardized, at least not initially, as it can be done with a @@ -80,7 +80,7 @@ or tagging. This raises the question of how to reconcile the efficient encoding backwards-compatibility goals. Specifically, we'd like to avoid the situation where a future version of WebAssembly has features -F1 and F2 and vendor V1 implements F1, assigning the next logical opcode indices to F1's new +F1 and F2 and vendor V1 implements F1, assigning the next logical opcode indices to F1's new opcodes, and V2 implements F2, assigning the same next logical opcode indices to F2's new opcodes and now a single binary has ambiguous semantics if it tries to use either F1 or F2. This type of non-linear feature addition is commonplace in JS and Web APIs and is guarded against by @@ -99,9 +99,9 @@ conflict-avoidance practices surrounding string names: * To avoid (over time) large index-space declaration sections that are largely the same between modules, finalized versions of standards would define named baseline index spaces that modules could optionally use as a starting point to further refine. - * For example, to use all of [v.1](V1.md) plus [SIMD](EssentialPostV1Features.md#fixed-width-simd) - the declaration could be "v1" followed by the list of SIMD opcodes used. - * This feature would also be most useful for people handwriting the [text format](V1.md#text-format). + * For example, to use all of [the MVP](MVP.md) plus [SIMD](EssentialPostMVPFeatures.md#fixed-width-simd) + the declaration could be "base" followed by the list of SIMD opcodes used. + * This feature would also be most useful for people handwriting the [text format](MVP.md#text-format). * However, such a version declaration does not establish a global "version" for the module or affect anything outside of the initialization of the index spaces; decoders would remain versionless and simply add cases for new *names* (as with current JS parsers). -- cgit v1.2.3