├── LICENSE └── README.md /LICENSE: -------------------------------------------------------------------------------- 1 | Creative Commons Legal Code 2 | 3 | CC0 1.0 Universal 4 | 5 | CREATIVE COMMONS CORPORATION IS NOT A LAW FIRM AND DOES NOT PROVIDE 6 | LEGAL SERVICES. DISTRIBUTION OF THIS DOCUMENT DOES NOT CREATE AN 7 | ATTORNEY-CLIENT RELATIONSHIP. CREATIVE COMMONS PROVIDES THIS 8 | INFORMATION ON AN "AS-IS" BASIS. CREATIVE COMMONS MAKES NO WARRANTIES 9 | REGARDING THE USE OF THIS DOCUMENT OR THE INFORMATION OR WORKS 10 | PROVIDED HEREUNDER, AND DISCLAIMS LIABILITY FOR DAMAGES RESULTING FROM 11 | THE USE OF THIS DOCUMENT OR THE INFORMATION OR WORKS PROVIDED 12 | HEREUNDER. 13 | 14 | Statement of Purpose 15 | 16 | The laws of most jurisdictions throughout the world automatically confer 17 | exclusive Copyright and Related Rights (defined below) upon the creator 18 | and subsequent owner(s) (each and all, an "owner") of an original work of 19 | authorship and/or a database (each, a "Work"). 20 | 21 | Certain owners wish to permanently relinquish those rights to a Work for 22 | the purpose of contributing to a commons of creative, cultural and 23 | scientific works ("Commons") that the public can reliably and without fear 24 | of later claims of infringement build upon, modify, incorporate in other 25 | works, reuse and redistribute as freely as possible in any form whatsoever 26 | and for any purposes, including without limitation commercial purposes. 27 | These owners may contribute to the Commons to promote the ideal of a free 28 | culture and the further production of creative, cultural and scientific 29 | works, or to gain reputation or greater distribution for their Work in 30 | part through the use and efforts of others. 31 | 32 | For these and/or other purposes and motivations, and without any 33 | expectation of additional consideration or compensation, the person 34 | associating CC0 with a Work (the "Affirmer"), to the extent that he or she 35 | is an owner of Copyright and Related Rights in the Work, voluntarily 36 | elects to apply CC0 to the Work and publicly distribute the Work under its 37 | terms, with knowledge of his or her Copyright and Related Rights in the 38 | Work and the meaning and intended legal effect of CC0 on those rights. 39 | 40 | 1. Copyright and Related Rights. A Work made available under CC0 may be 41 | protected by copyright and related or neighboring rights ("Copyright and 42 | Related Rights"). Copyright and Related Rights include, but are not 43 | limited to, the following: 44 | 45 | i. the right to reproduce, adapt, distribute, perform, display, 46 | communicate, and translate a Work; 47 | ii. moral rights retained by the original author(s) and/or performer(s); 48 | iii. publicity and privacy rights pertaining to a person's image or 49 | likeness depicted in a Work; 50 | iv. rights protecting against unfair competition in regards to a Work, 51 | subject to the limitations in paragraph 4(a), below; 52 | v. rights protecting the extraction, dissemination, use and reuse of data 53 | in a Work; 54 | vi. database rights (such as those arising under Directive 96/9/EC of the 55 | European Parliament and of the Council of 11 March 1996 on the legal 56 | protection of databases, and under any national implementation 57 | thereof, including any amended or successor version of such 58 | directive); and 59 | vii. other similar, equivalent or corresponding rights throughout the 60 | world based on applicable law or treaty, and any national 61 | implementations thereof. 62 | 63 | 2. Waiver. To the greatest extent permitted by, but not in contravention 64 | of, applicable law, Affirmer hereby overtly, fully, permanently, 65 | irrevocably and unconditionally waives, abandons, and surrenders all of 66 | Affirmer's Copyright and Related Rights and associated claims and causes 67 | of action, whether now known or unknown (including existing as well as 68 | future claims and causes of action), in the Work (i) in all territories 69 | worldwide, (ii) for the maximum duration provided by applicable law or 70 | treaty (including future time extensions), (iii) in any current or future 71 | medium and for any number of copies, and (iv) for any purpose whatsoever, 72 | including without limitation commercial, advertising or promotional 73 | purposes (the "Waiver"). Affirmer makes the Waiver for the benefit of each 74 | member of the public at large and to the detriment of Affirmer's heirs and 75 | successors, fully intending that such Waiver shall not be subject to 76 | revocation, rescission, cancellation, termination, or any other legal or 77 | equitable action to disrupt the quiet enjoyment of the Work by the public 78 | as contemplated by Affirmer's express Statement of Purpose. 79 | 80 | 3. Public License Fallback. Should any part of the Waiver for any reason 81 | be judged legally invalid or ineffective under applicable law, then the 82 | Waiver shall be preserved to the maximum extent permitted taking into 83 | account Affirmer's express Statement of Purpose. In addition, to the 84 | extent the Waiver is so judged Affirmer hereby grants to each affected 85 | person a royalty-free, non transferable, non sublicensable, non exclusive, 86 | irrevocable and unconditional license to exercise Affirmer's Copyright and 87 | Related Rights in the Work (i) in all territories worldwide, (ii) for the 88 | maximum duration provided by applicable law or treaty (including future 89 | time extensions), (iii) in any current or future medium and for any number 90 | of copies, and (iv) for any purpose whatsoever, including without 91 | limitation commercial, advertising or promotional purposes (the 92 | "License"). The License shall be deemed effective as of the date CC0 was 93 | applied by Affirmer to the Work. Should any part of the License for any 94 | reason be judged legally invalid or ineffective under applicable law, such 95 | partial invalidity or ineffectiveness shall not invalidate the remainder 96 | of the License, and in such case Affirmer hereby affirms that he or she 97 | will not (i) exercise any of his or her remaining Copyright and Related 98 | Rights in the Work or (ii) assert any associated claims and causes of 99 | action with respect to the Work, in either case contrary to Affirmer's 100 | express Statement of Purpose. 101 | 102 | 4. Limitations and Disclaimers. 103 | 104 | a. No trademark or patent rights held by Affirmer are waived, abandoned, 105 | surrendered, licensed or otherwise affected by this document. 106 | b. Affirmer offers the Work as-is and makes no representations or 107 | warranties of any kind concerning the Work, express, implied, 108 | statutory or otherwise, including without limitation warranties of 109 | title, merchantability, fitness for a particular purpose, non 110 | infringement, or the absence of latent or other defects, accuracy, or 111 | the present or absence of errors, whether or not discoverable, all to 112 | the greatest extent permissible under applicable law. 113 | c. Affirmer disclaims responsibility for clearing rights of other persons 114 | that may apply to the Work or any use thereof, including without 115 | limitation any person's Copyright and Related Rights in the Work. 116 | Further, Affirmer disclaims responsibility for obtaining any necessary 117 | consents, permissions or other rights required for any use of the 118 | Work. 119 | d. Affirmer understands and acknowledges that Creative Commons is not a 120 | party to this document and has no duty or obligation with respect to 121 | this CC0 or use of the Work. 122 | -------------------------------------------------------------------------------- /README.md: -------------------------------------------------------------------------------- 1 | # AluVM Specifications 2 | 3 | Specification of AluVM (pronounced as "alluvium", [ɑlˈluːvium]) instruction set 4 | architecture and assembly language (AluVM Assembly or AluAsm). 5 | 6 | AluVM is a pure functional register-based highly deterministic & exception-less 7 | instruction set architecture (ISA) and virtual machine (VM) without random 8 | memory access, capable of performing arithmetic operations, including operations 9 | on elliptic curves. The AluVM ISA can be extended by the environment 10 | running the virtual machine (*host environment*), providing ability to load 11 | data to the VM registers and support application-specific instructions (like 12 | SIMD). 13 | 14 | The main purpose for ALuVM is to be used in distributed systems whether 15 | robustness, platform-independent determinism are more important than the speed 16 | of computation. The main area of AluVM applications (using appropriate ISA 17 | extensions) is blockchain environments, consensus-critical computations, 18 | multiparty computing (including deterministic machine learning), 19 | client-side-validation, sandboxed Internet2 computing and genetic algorithms. 20 | 21 | 22 | ## Runtime environments and ISA extensions 23 | 24 | The current list of AluVM runtime environments (providing corresponding ISA 25 | extensions) include: 26 | - AluRE (ALU Runtime Environment, multiparty computations, machine learning and 27 | sandboxed computing for Internet2/Web4 applications running on client-side). 28 | Supports following ISA Extensions: 29 | * ALURE (User I/O), 30 | * WEB4 (Networking I/O), 31 | * SIMD. 32 | - RGB Core (client-side-validated smart contracts); 33 | * RGB: access to RGB contract data, 34 | * BTC: access to bitcoin blockchain data, 35 | - LNP Core (lightning network). 36 | * BTC: access to bitcoin blockchain data, 37 | * LNC: access to lightning network channel data 38 | * WEB4 (Internet2 & Web4 I/O), 39 | * SIMD. 40 | - REBICA (runtime environment for biologically-inspired computing architectures) 41 | providing ISA extension with the same name. 42 | 43 | ## Design 44 | 45 | VM is purely functional, meaning that it treats all computation as the 46 | evaluation of mathematical functions and does not have any side effects. 47 | 48 | To make VM exception-less and robust the following design decisions were 49 | implemented: 50 | - no side effects of any instruction outside of the well defined VM state, and 51 | thus: 52 | * absence of stack (however it may be emulated using registers); 53 | * absence of random memory access; 54 | - two distinct byte encodings of the full VM state always represent two distinct 55 | states (this requires special handling of `NaN` and `±0` values for float 56 | registers); 57 | - VM state is represented by a finite set of register values with predefined 58 | bit dimensionality; 59 | - all registers have a special "uninitialized/no value" state; 60 | - all registers at the start of the program are always initialized into; 61 | "no value" state, after which some registers are filled with input values; 62 | - impossible arithmetic operations (like division on zero) instead of generating 63 | exception bring destination register into "no value" state; 64 | - all instructions accessing the register data must check for "no value" state 65 | in the source registers and if any of them has it, put the destination 66 | register into "no value" (`None`) state; 67 | - each instruction modifies only those non-control flow registers which are 68 | explicitly provided as the instruction arguments; 69 | - the set of the control-flow register modification which may happen during 70 | operation are part of this formal specification; 71 | - there are no byte sequences which can't be interpreted as a valid VM 72 | instruction, so arbitrary code jumps can't lead to an exception; 73 | - any two distinct byte strings always represent strictly distinct programs. 74 | 75 | ### Registers 76 | 77 | AluVM operates five sets of registers: 78 | - Arithmetic integer registers, or `A`-registers (prefixed with `a` 79 | in mnemonics); 80 | - Arithmetic float registers, or `F`-registers (prefixed with `f` in mnemonics); 81 | - General R-registers, used in cryptography (prefixed with `r` in mnemonics); 82 | - Bytestring registers, or `S`-registers (prefixed with `s` in mnemonics); 83 | - Control flow registers, named individually 84 | 85 | There are 8 types of integer and float arithmetic and general registers, which 86 | differ in their bit size. For each type of these, as for the bytestring 87 | registers, there are 32 individual registers, indexed with 1..=32 numbers put in 88 | square brackets in mnemonics. 89 | 90 | **Arithmetic integer register types:** 91 | - 8-bit (`a8`) 92 | - 16-bit (`a16`) 93 | - 32-bit (`a32`) 94 | - 64-bit (`a64`) 95 | - 128-bit (`a128`) 96 | - 256-bit (`a256`) 97 | - 512-bit (`a512`) 98 | - 1024-bit (`a1024`) 99 | 100 | **Arithmetic float register types:** 101 | - 16-bit bfloat16 format used in machine learning (`f16b`) 102 | - 16-bit IEEE-754 binary16 half-precision (`f16`) 103 | - 32-bit IEEE-754 binary32 single-precision (`f32`) 104 | - 64-bit IEEE-754 binary64 double-precision (`f64`) 105 | - 80-bit IEEE-754 extended precision (`f80`) 106 | - 128-bit IEEE-754 binary128 quadruple precision (`f128`) 107 | - 256-bit IEEE-754 binary256 octuple precision (`f256`) 108 | - 512-bit tapered floating point (`f512`), described below 109 | 110 | **General register types:** 111 | - 128-bit (`r128`) 112 | - 160-bit (`r160`), most useful for RIPEMD-160 hashing 113 | - 256-bit (`r256`) 114 | - 512-bit (`r512`) 115 | - 1024-bit (`r1024`), most useful for RSA key handling 116 | - 2048-bit (`r2048`), most useful for RSA key handling 117 | - 4098-bit (`r4096`), most useful for RSA key handling 118 | - 8192-bit (`r8192`), most useful for RSA key handling 119 | 120 | **Bytestring registers** is a single family of 256 registers each of which is 121 | a combination of 16-bit string length (not accessible directly by the 122 | instructions) and 2^16-byte long value. 123 | 124 | **Control flow registers:** 125 | - 1-bit status register `st0` 126 | - 16-bit jump counting register `cy0` 127 | - 16-bit call stack pointer register `cp0` 128 | - Block of 2^16 call stack registers `cs0[0..2^16]` 129 | 130 | 131 | ### Arithmetics 132 | 133 | Arithmetic operations has the following degrees of freedom: 134 | 135 | 1. **Number encoding**: the per-bit layout of the register mapping to the actual 136 | arithmetical number value: 137 | - Unsigned integer: little-endian byte-encoded integer data occupying full 138 | length of the register 139 | - Signed integer: the same as unsigned integer with the highest bit (the 140 | highest bit of the last byte) reserved for the sign: `0` value indicates 141 | positive sign, `1` indicates negative sign: `(-1)^sign_bit`. 142 | - IEEE-754 floating point matching the bit length of the registry, with 143 | special extension for tapered floating point encoding in 512-bit floating 144 | registers and machine-learning popular format of `bfloat16`. 145 | 2. **Exceptions** 146 | - Impossible arithmetic operation (0/0, Inf/inf) always sets the destination 147 | register into `None` state (corresponding to `NaN` value of IEEE-754, i.e. 148 | all registers with `NaN` must report `None` state instead). 149 | - Operation resulting in the value which can't fit the bit dimensions under 150 | a used encoding, including representation of infinity for integer 151 | encodings (`x/0 if x != 0`) results in: 152 | * for float underflows, subnormally encoded number, 153 | * for `x/0 if x != 0` on float numbers, `±Inf` float value, 154 | * for overflows in integer `checked` operations and floats (NB: float 155 | operations are always `checked`), `None` value, setting `st0` to `false`, 156 | * for overflows in integer `wrapped` operations, modulo division on the 157 | maximum register value; 158 | 159 | As a result, most of the arithmetic operations has to be provided with flags 160 | specifying which of the encoding and exception handling should be used: 161 | - **Integer encodings** has two flags: 162 | * one for signed/unsigned variant of the encoding 163 | * one for checked or wrapped variant of exception handling 164 | - **Float encoding** has 4 variants of rounding, matching IEEE-754 options. 165 | 166 | Thus, many arithmetic instructions have 8 variants, indicating the used encoding 167 | (unsigned, signed integer or float) and operation behaviour in situation when 168 | resulting value does not fit into the register (overflow or wrap for integers 169 | and one of four rounding options for floats). These operations include 170 | - addition 171 | - subtraction 172 | - multiplication 173 | 174 | Division operation can't overflow in case of integers, however in this case it 175 | requires specification of the rounding algorithm. So the same bit used to 176 | specify overflow or wrapping behaviour in this case is used to detect rounding 177 | algorithm: euclidean or non-euclidean rounding. 178 | 179 | These operations are performed by *flagged arithmetic instructions*. 180 | 181 | Each of the flagged arithmetic operations must set the value of `st0` register 182 | to `false` under the following conditions: 183 | 184 | - if overflow has happened for `checked` integer arithmetics; 185 | - if a float operation resulted in overflow, setting destination register to 186 | `±Inf` (but not if the `±Inf` value resulted from a non-overflowing operation, 187 | like `0 + Inf = Inf`); 188 | - if a float operation resulted in `NaN` value, i.e. for impossible arithmetic 189 | operations (see above); 190 | 191 | In all other cases, including overflows with wrapped flag set, the flagged 192 | operations must set `st0` to `true`. 193 | 194 | Some number encodings allows additional arithmetic operations: 195 | - Modulo division (division reminder) for unsigned integers 196 | - Negation for floats and signed integers 197 | - Absolute value / sign detection for singed integers and floats 198 | 199 | These operations never overflow/underflow and modulo division on zero will 200 | always result in `None` value in a destination. Instructions performing these 201 | operations are named *unflagged arithmetic instructions* and they do not modify 202 | the value of `st0` register. 203 | 204 | **Except all aforementioned rules, the implementation of the float arithmetics 205 | must strictly follow IEEE-754 standard.** 206 | 207 | 208 | ## Instruction set 209 | 210 | ### 1. Arithmetics 211 | 212 | Flagged arithmetic instructions operate two source registers and one destination 213 | register and are represented by a 40-bit value with the following structure: 214 | 215 | Bits | Bit count | Meaning | Possible values 216 | ------:| ---------:| ----------- | ------------------- 217 | 0-7 | 8 | Operation | add, sub, mul, div 218 | 8-15 | 8 | Flags | unsigned_checked, unsigned_wrapped, signed_checked, signed_wrapped, float_near, float_ceil, float_floor, float_to0 219 | 16-23 | 8 | Source 1 | number of the first source register 220 | 24-31 | 8 | Source 2 | number of the second source register 221 | 32-39 | 8 | Destination | number of the destination register 222 | 223 | For assembly representation the core arithmetic operations are written with 224 | the flags provided as the operation suffix 225 | 226 | ```aluasm 227 | add:uc a8[0],a8[1],a16[2] ; will perform unchecked unsigned addition 228 | ; of the values in the first and second 229 | ; 8-bit integer registers a8[0] and a8[1] 230 | ; putting result of operation into a8[2] 231 | 232 | add:n f32[0],f32[1],f32[2] ; will perform addition with rounding 233 | ; to the nearest value for the first and 234 | ; second 32-bit float register (f32[0] 235 | ; and f32[1]) putting the result of the 236 | ; operation into f32[2] 237 | ``` 238 | 239 | This will have a bytcode representation of `0x6400000102` and `0x6404202122`, 240 | where first bytes (`0x64`) are the id of `add` instruction, the second byte is 241 | the flags for number encoding (indicating which set of arithmetic registers is 242 | used, integer or float) and operation variant and the last three bytes are 243 | indexes of the registers. 244 | --------------------------------------------------------------------------------