Merge pull request #194 from ewasm/wasm-lowercase

use Wasm, not WASM

Author: axic

Diff for: README.md

@@ -13,9 +13,9 @@ This repository contains documents describing the design and high-level overview
 Please review the [WebAssembly](http://webassembly.org/) [design](http://webassembly.org/docs/high-level-goals/) and [instruction set](https://webassembly.github.io/spec/core/appendix/index-instructions.html#index-instr) first. (You can also make a pull request or raise an issue at the [Wasm Github repo](https://github.com/WebAssembly/design).)
 
 A few key points:
-* WebAssembly defines an instruction set, intermediate source format (WAST) and a binary encoded format (WASM).
+* WebAssembly defines an instruction set, intermediate source format (wast) and a binary encoded format (wasm).
 * WebAssembly has a few higher level features, such as the ability to import and execute outside methods defined via an interface.
-* [LLVM](https://llvm.org/) includes a WebAssembly backend to generate WASM output.
+* [LLVM](https://llvm.org/) includes a WebAssembly backend to generate Wasm output.
 * Major browser JavaScript engines will notably have native support for
   WebAssembly, including but not limited to: Google's
   [V8](https://github.com/v8/v8) engine (Node.js and Chromium-based browsers),
@@ -32,7 +32,7 @@ A few key points:
 
 ## What is Ethereum flavored WebAssembly (ewasm)?
 
-ewasm is a restricted subset of WASM to be used for contracts in Ethereum.
+ewasm is a restricted subset of Wasm to be used for contracts in Ethereum.
 
 ewasm:
 * specifies the [VM semantics](./vm_semantics.md)

Diff for: backwards_compatibility.md

@@ -14,9 +14,9 @@ cost. The fee schedule for ewasm is yet to be specified.
 ## Identification of code
 We assume there is some sort of code handler function that all clients have 
 implemented. The code handler identifies the instruction set type by whether it
-starts with WASM's magic number or not.
+starts with Wasm's magic number or not.
 
-The WASM magic number is the following byte sequence: `0x00, 0x61, 0x73, 0x6d`.
+The Wasm magic number is the following byte sequence: `0x00, 0x61, 0x73, 0x6d`.
 
 ## Solidity
 Support of compiling to ewasm can be accomplished by adding a new backend to

Diff for: comparison.md

@@ -1,4 +1,4 @@
-# WASM
+# Wasm
 ### Good
 * limited well defined non-determinism
 * performant (near native speed)
@@ -21,7 +21,7 @@
 * not stable
 * large surface (ISA) that VM implementors would have to deal with
 
-Response from Derek Schuff (one of the engineers for PNaCl) from Google on WASM vs LLVM
+Response from Derek Schuff (one of the engineers for PNaCl) from Google on Wasm vs LLVM
 
 >I'm guessing you are unfamiliar with PNaCl. This is more or less the approach taken by PNaCl; i.e. use LLVM as the starting point for a wire format. It turns out that LLVM IR/bitcode by itself is neither portable nor stable enough to be used for this purpose, and it is designed for compiler optimizations, it has a huge surface area, much more than is needed for this purpose. PNaCl solves these problems by defining a portable target triple (an architecture called "le32" used instead of e.g. i386 or arm), a subset of LLVM IR, and a stable frozen wire format based on LLVM's bitcode. So this approach (while not as simple as "use LLVM-IR directly") does work. However LLVM's IR and bitcode formats were designed (respectively) for use as a compiler IR and for temporary file serialization for link-time optimization. They were not designed for the goals we have, in particular a small compressed distribution format and fast decoding. We think we can do much better for wasm, with the experience we've gained from PNaCl
 

Diff for: contract_interface.md

@@ -4,7 +4,7 @@ The Ewasm Contract Interface (ECI) specifies the structure of a contract module.
 
 ### Wire format
 
-Every contract must be stored in the [WebAssembly Binary Encoding](https://github.com/WebAssembly/design/blob/master/BinaryEncoding.md) format (in short, WASM bytecode).
+Every contract must be stored in the [WebAssembly Binary Encoding](https://github.com/WebAssembly/design/blob/master/BinaryEncoding.md) format (in short, Wasm bytecode).
 
 ### Imports
 

Diff for: determining_wasm_gas_costs.md

@@ -3,7 +3,7 @@
 The goal of this document is to describe the process of determining gas costs
 for ewasm instructions.
 
-Each WASM opcode is assigned an appropriate Intel IA-32 (x86) opcode (or a
+Each Wasm opcode is assigned an appropriate Intel IA-32 (x86) opcode (or a
 series of opcodes). These opcodes have a fixed cycle count (called *latency*
 by Intel). We are selecting one specific CPU model from the Haswell architecture
 (family: `06`, model `3C`). This equals to CPUs produced in 2014.
@@ -35,13 +35,13 @@ by the *metering injection contract*.
 ## Gas vs. *Particles*
 
 The current gas handling fields do not offer the precision needed assuming that
-running WASM opcodes takes significantly less processing power compared to EVM1
+running Wasm opcodes takes significantly less processing power compared to EVM1
 opcodes.
 
-*Rationale*: EVM1 opcodes operate on 256-bits of data, while WASM opcodes are limited
+*Rationale*: EVM1 opcodes operate on 256-bits of data, while Wasm opcodes are limited
 to at most 64-bits, which results in executing four instructions in the best
 case to match EVM1. Most arithmetic instructions in EVM1 cost 3 gas, which would
-amount to 0.75 gas for most 64-bit WASM instructions.
+amount to 0.75 gas for most 64-bit Wasm instructions.
 
 Internally, ewasm gas measurements should be recorded in a 64 bit variable
 with 4 decimal digits precision. We call this *particles*. It is a minor

Diff for: faq.md

@@ -1,11 +1,11 @@
 # FAQ
 
-WASM's FAQ can be found [here](https://github.com/WebAssembly/design/blob/master/FAQ.md) 
+Wasm's FAQ can be found [here](https://github.com/WebAssembly/design/blob/master/FAQ.md) 
 
 ## Is ewasm primarily the replacement for EVM?  
-Currently it is being researched as a replacement instruction set for EVM1. Other instruction sets have been considered but so far WASM seems the most suitable.
+Currently it is being researched as a replacement instruction set for EVM1. Other instruction sets have been considered but so far Wasm seems the most suitable.
 
-## What are alternatives to WASM?  
+## What are alternatives to Wasm?  
 Some that have been considered are [here](./comparison.md)
 
 ## What are the benefits?   
@@ -23,10 +23,10 @@ Not off the bat, a transcompiler will have to be created to compile existing EVM
 ## How does ewasm handle non-determinism when a variety of programming languages are allowed to be used?
 Part of the project goal is to eliminate nasal-demons. It's in the MVP. There are still a couple of edge case like sign values on NaNs but they can be canonicalized by AST transforms.  
 
-## Will ewasm be compatible with WASM?  
-Yes, the Ethereum System Interface can also be written in WASM.
+## Will ewasm be compatible with Wasm?  
+Yes, the Ethereum System Interface can also be written in Wasm.
 
-## Can ewasm be built even if WASM is not currently complete or will we need to wait for its completion/MVP?   
+## Can ewasm be built even if Wasm is not currently complete or will we need to wait for its completion/MVP?   
 Yes, but we would lose the "Shared tooling" benefit. So It might not make sense.
 
 ## Does ewasm use synchronous or asynchronous methods?

Diff for: metering.md

@@ -2,7 +2,7 @@
 
 Given a set of operations and a corresponding set of costs for each operation we can deterministically run computation for any number of cost units by summing up the costs on the execution of each operation. We call the cost units here "gas" and it stands as a estimation for computational time. 
 
-## Metering in WASM
+## Metering in Wasm
 
 The following has been implemented [here](https://github.com/ewasm/wasm-metering)
 
@@ -25,7 +25,7 @@ i64.const <cost>
 call $meter
 ```
 
-And a metering function `$meter`. The meter function has a signature of `(type (func (param i64)))`. Internally this function should keep a running sum and if that sum grows larger than a given threshold, end the program's execution. The metering function can be imbedded in the binary itself or can use wasm's import to define it externally. 
+And a metering function `$meter`. The meter function has a signature of `(type (func (param i64)))`. Internally this function should keep a running sum and if that sum grows larger than a given threshold, end the program's execution. The metering function can be embedded in the binary itself or can use wasm's import to define it externally. 
 
 Then given an array of opcodes we iterate the array and divided into segments that start with one of the `branching_ops`
 

Diff for: rationale.md

@@ -3,8 +3,8 @@
 * Fast & Efficient: To truly distinguish Ethereum as the World Computer we need to have a very performant VM. The current architecture of the VM is one of the greatest blockers to raw performance. WebAssembly aims to execute at near native speed by taking advantage of common hardware capabilities available on a wide range of platforms. This will open the door to a wide array of uses that require performance/throughput. 
 * Security: With the add performance gains from ewasm we will be able to implement parts of Ethereum such as the precompiled contract in the VM itself which will minimize our trusted computing base.
 * Standardized Instruction Set: WebAssembly is currently being designed as an open standard by a W3C Community Group and is actively being developed by engineers from Mozilla, Google, Microsoft, and Apple.
-* Toolchain Compatibility: A LLVM front-end for WASM is part of the MVP. This will allow developers to write contracts and reuse applications written in common languages such as C/C++, go and rust.
-* Portability: WASM is targeted to be deployed in all the major web browsers which will result in it being one of the most widely deployed VM architecture. Contracts compiled to ewasm will share compatibility with any standard WASM environment. Which will make running a program either directly on Ethereum, on a cloud hosting environment, or on one's local machine - a frictionless process.
+* Toolchain Compatibility: A LLVM front-end for Wasm is part of the MVP. This will allow developers to write contracts and reuse applications written in common languages such as C/C++, go and rust.
+* Portability: Wasm is targeted to be deployed in all the major web browsers which will result in it being one of the most widely deployed VM architecture. Contracts compiled to ewasm will share compatibility with any standard Wasm environment. Which will make running a program either directly on Ethereum, on a cloud hosting environment, or on one's local machine - a frictionless process.
 * Optional And Flexible Metering: Metering the VM adds overhead but is essential for running untrusted code. If code is trusted then metering maybe optional. ewasm defines metering as an optional layer to accommodate for these use cases.
 * Furthermore some of [Wasm's top design goals](https://github.com/WebAssembly/design/blob/master/HighLevelGoals.md) are largely applicable to Ethereum, including: