https://DevOpsCloud.io -- Cloud Monk Losang Jinpa, Ph.D., MCSE/MCT, GitOps DevOps Engineer

Wasm

Main article is at WebAssembly. This article is just for search links below.

Return WebAssembly (Wasm) Development Tools, GitHub star ranking for organizations, GitHub star ranking for repositories, GitOps or GitHub

Snippet from Wikipedia: WebAssembly: WebAssembly (Wasm) defines a portable binary-code format and a corresponding text format for executable programs as well as software interfaces for facilitating communication between such programs and their host environment.
The main goal of WebAssembly is to facilitate high-performance applications on web pages, but it is also designed to be usable in non-web environments. It is an open standard intended to support any language on any operating system, and in practice many of the most popular languages already have at least some level of support.
Announced in 2015 (2015) and first released in March 2017 (2017-3), WebAssembly became a World Wide Web Consortium recommendation on 5 December 2019 and it received the Programming Languages Software Award from ACM SIGPLAN in 2021. The World Wide Web Consortium (W3C) maintains the standard with contributions from Mozilla, Microsoft, Google, Apple, Fastly, Intel, and Red Hat.

Creative Commons Attribution-Share Alike 4.0

https://webassembly.github.io/spec/core/_download/WebAssembly.pdf

Introduction

WebAssembly (abbreviated Wasm [1]) is a safe, portable, low-level code format designed for efficient execution and compact representation. Its main goal is to enable high performance applications on the Web, but it does not make any Web-specific assumptions or provide Web-specific features, so it can be employed in other environments as well.

WebAssembly is an open standard developed by a W3C Community Group.

This document describes version 2.0 (Draft 2024-11-12) of the core WebAssembly standard. It is intended that it will be superseded by new incremental releases with additional features in the future.

Design Goals The design goals of WebAssembly are the following:

Fast, safe, and portable semantics: Fast: executes with near native code performance, taking advantage of capabilities common to all contemporary hardware. Safe: code is validated and executes in a memory-safe [2], sandboxed environment preventing data corruption or security breaches. Well-defined: fully and precisely defines valid programs and their behavior in a way that is easy to reason about informally and formally. Hardware-independent: can be compiled on all modern architectures, desktop or mobile devices and embedded systems alike. Language-independent: does not privilege any particular language, programming model, or object model. Platform-independent: can be embedded in browsers, run as a stand-alone VM, or integrated in other environments. Open: programs can interoperate with their environment in a simple and universal manner. Efficient and portable representation: Compact: has a binary format that is fast to transmit by being smaller than typical text or native code formats. Modular: programs can be split up in smaller parts that can be transmitted, cached, and consumed separately. Efficient: can be decoded, validated, and compiled in a fast single pass, equally with either just-in-time (JIT) or ahead-of-time (AOT) compilation. Streamable: allows decoding, validation, and compilation to begin as soon as possible, before all data has been seen. Parallelizable: allows decoding, validation, and compilation to be split into many independent parallel tasks. Portable: makes no architectural assumptions that are not broadly supported across modern hardware. WebAssembly code is also intended to be easy to inspect and debug, especially in environments like web browsers, but such features are beyond the scope of this specification.

[1] A contraction of “WebAssembly”, not an acronym, hence not using all-caps. [2] No program can break WebAssembly’s memory model. Of course, it cannot guarantee that an unsafe language compiling to WebAssembly does not corrupt its own memory layout, e.g. inside WebAssembly’s linear memory. Scope At its core, WebAssembly is a virtual instruction set architecture (virtual ISA). As such, it has many use cases and can be embedded in many different environments. To encompass their variety and enable maximum reuse, the WebAssembly specification is split and layered into several documents.

This document is concerned with the core ISA layer of WebAssembly. It defines the instruction set, binary encoding, validation, and execution semantics, as well as a textual representation. It does not, however, define how WebAssembly programs can interact with a specific environment they execute in, nor how they are invoked from such an environment.

Instead, this specification is complemented by additional documents defining interfaces to specific embedding environments such as the Web. These will each define a WebAssembly application programming interface (API) suitable for a given environment.

Security Considerations WebAssembly provides no ambient access to the computing environment in which code is executed. Any interaction with the environment, such as I/O, access to resources, or operating system calls, can only be performed by invoking functions provided by the embedder and imported into a WebAssembly module. An embedder can establish security policies suitable for a respective environment by controlling or limiting which functional capabilities it makes available for import. Such considerations are an embedder’s responsibility and the subject of API definitions for a specific environment.

Because WebAssembly is designed to be translated into machine code running directly on the host’s hardware, it is potentially vulnerable to side channel attacks on the hardware level. In environments where this is a concern, an embedder may have to put suitable mitigations into place to isolate WebAssembly computations.

Dependencies WebAssembly depends on two existing standards:

IEEE 754, for the representation of floating-point data and the semantics of respective numeric operations. Unicode, for the representation of import/export names and the text format. However, to make this specification self-contained, relevant aspects of the aforementioned standards are defined and formalized as part of this specification, such as the binary representation and rounding of floating-point values, and the value range and UTF-8 encoding of Unicode characters.

Note The aforementioned standards are the authoritative source of all respective definitions. Formalizations given in this specification are intended to match these definitions. Any discrepancy in the syntax or semantics described is to be considered an error.

https://webassembly.github.io/spec/core/intro/introduction.html