## 4 Tools for WebAssembly Development
### WebAssembly Standardized Features for Existing Web Browsers and Tools
When instantiating a Wasm module using a _moduleObject_, an exception of type _LinkError_ is thrown if a global value has the type v128 and the imported object is not a _Wasm.Global_. * **Tail Calls** This scheme aims to enable tail call optimizations in Wasm, which are currently prohibited. Tail call elimination is crucial for correct and efficient implementations of languages that rely on this optimization, as well as for certain compilation and optimization techniques such as dynamic recompilation, tracing, and CPS. By introducing tail call support, Wasm can better handle control constructs such as co-routines, continuations, and finite state machines. Tail calls involve unwinding the current call frame before performing the call, regardless of any differences between the caller and callee functions. This proposal introduces explicit tail call instructions distinct from the regular call instructions that explicitly disallow TCE. Tail calls behave as a combination of a return instruction followed by a call instruction, unwinding the operand stack similar to a return and keeping only the necessary call arguments. While tail calls to host functions cannot guarantee tail behavior (beyond the scope of the specification), tail calls across Wasm module boundaries do guarantee tail behavior. Tail calls are performed using separate call instructions designed explicitly for tail calls. This proposal introduces a tail version of each existing call instruction. An alternative approach involving a single instruction prefix applicable to every call instruction was considered and rejected by the _WebAssembly Community Group_. Although Wasm may include additional call instructions in the future, such as call_ref, the use of instruction prefixes as modifiers is not employed elsewhere in the Wasm specification. Tail calls behave as a combination of return and call instructions, as they unwind the operand stack similar to a return instruction. They only retain the necessary call arguments. It is important to note that tail calls to host functions cannot guarantee tail behavior, whereas tail calls across Wasm module boundaries do ensure tail behavior. Tail call instructions are stack-polymorphic due to their combining call and return operations. Previously, there was a question of whether tail calls should induce different function types. Four possibilities were considered: distinguishing tail-callees by type, distinguishing tail-callees by type, both, or neither. After careful consideration, the fourth option was chosen as the simplest option conceptually. Experimental validation showed no significant performance benefit to the first option, and bifurcating the function space with the third option could lead to difficulties with function tables and dynamic indirection. Validating the new instructions combines the typing rules for returns and the existing call instructions, resulting in stack-polymorphic behavior. The type of a _return_call_ instruction with function index x is derived from the type of the function referred to by x. If x has a function type [_t1*_] -> [_t2*_], then return_call x has the type [_t3*_t1*_] -> [_t4*_], where t3* and t4* can be any types provided that the current function has a return type of [t2*]. The same principle applies to _return_call_indirect_ instructions. The execution semantics of the new instructions involve popping the call operands, clearing and popping the topmost stack frame like a return instruction, pushing back the operands, and then delegating to the semantics of the corresponding plain call instructions. The reserved opcodes following the existing call instructions are used for the new instructions in the binary format; specifically, _return_call_ is represented by _0x12_ and _return_call_indirect_ is represented by 0x13. Table 8 presents a comparison of existing WebAssembly standardized features in various web browsers and tools.