## 4 Tools for WebAssembly Development
### WebAssembly Standardized Features for Existing Web Browsers and Tools
The Non-Trapping Float-to-Int Conversions proposal presents a solution to the undefined behavior of float-to-int conversions in LLVM and introduces saturating versions of the instructions. By providing consistent and non-trapping conversions, this proposal aims to enhance the reliability and predictability of float-to-int conversions in Wasm. * _i32.extend8.s: sign-extend a signed 8-bit integer to a 32-bit integer._
- _i32.extend16.s: sign-extend a signed 16-bit integer to a 32-bit integer._
- _i64.extend8.s: sign-extend a signed 8-bit integer to a 64-bit integer._
- _i64.extend16.s: sign-extend a signed 16-bit integer to a 64-bit integer._
- _i64.extend32.s: sign-extend a signed 32-bit integer to a 64-bit integer._ It was later added for consistency, as its behavior differs from _i64.extend s/i32_. The instruction syntax and binary format are modified to accommodate the new sign-extension operators. The instruction syntax is expanded to include the new operators, while the binary format assigns specific values to each operator for encoding purposes. The Sign-Extension Operators proposal offers an enhancement to Wasm by introducing new instructions that enable sign-extension for various integer sizes. By incorporating these sign-extension operators, Wasm gains increased flexibility and functionality in working with signed integer values. * **Fixed-Width SIMD** This specification presents an extension to Wasm that introduces a 128-bit packed Single Instruction Multiple Data (SIMD) feature. This extension is designed to efficiently leverage the capabilities of current instruction set architectures commonly used in hardware. The primary motivation behind this proposal is to enable Wasm to utilize the SIMD instructions available in hardware, thereby achieving performance levels close to native execution speed. SIMD instructions in hardware allow simultaneous computations on packed data within a single instruction, often employed to enhance multimedia application performance. This proposal defines a portable subset of operations that closely aligns with commonly used SIMD instructions found in modern hardware. The Wasm extension introduces a new value type called _v128_ that is specifically tailored for SIMD operations. The v128 type corresponds to a 128-bit representation with bits numbered from 0 to 127. It serves as a mapping to a vector register in SIMD instruction set architectures. The interpretation of the 128 bits within the vector register is determined by individual instructions. When representing a v128 value as 16 bytes, bits 0-7 are stored in the first byte, with bit 0 as the least significant bit (LSB); bits _8-15_ are stored in the second byte, and so on. The v128 SIMD type is versatile and capable of representing various types of packed data. For example, it can represent four 32-bit floating-point values, eight 16-bit signed or unsigned integer values, and more. Instructions in this specification follow a naming convention: _interpretation.operation_. The _interpretation_ prefix indicates how the bytes of the _v128_ type are interpreted by the _operation_. For instance, the _f32x4.extract_lane_ and _i64x2.extract_lane_ instructions perform the same operation of extracting the scalar value of a vector lane. However, the _f32x4.extract_lane_ instruction returns a 32-bit floating-point value, while the _i64x2.extract_lane_ instruction returns a 64-bit integer value. The v128 vector type interpretation treats the vector as a collection of bits. The _vlane_widthxn_ interpretations (e.g., v32x4) view the vector as n lanes, each consisting of _lane_width_ bits. The _lane_widthxn_ interpretations (e.g., i32x4 or f32x4) treat the vector as n lanes, with each lane having a type of _lane_width_. Attempting to access SIMD types in Wasm module imports or exports from JavaScript results in an error. If an imported function in JavaScript expects or returns a _v128_-type argument or result, invoking that function immediately throws a _TypeError_.