64 bit arithmetic soft fork

The article "Arithmetic Opcodes: What Could They Look Like?" by Rusty Russell discusses the potential simplification of arithmetic opcodes by only dealing with non-negative numbers. This approach could streamline certain processes, as negative considerations often add complexity to programming tasks. The suggestion to remove normalization from left and right shift operations (LSHIFT and RSHIFT) stems from the way Elements implementations currently handle leading zeroes and the sign bit—by eliminating them after shifts. Normalization can lead to malleability issues; for instance, various inputs such as 0x01, 0x0100, or 0x010000 could yield the same result when subjected to a '5 LSHIFT' operation.

The reliance on __uint128_t support in compilers like GCC and clang raises concerns about the compatibility with other compilers, potentially discouraging their use. The article suggests the necessity for a mechanism that facilitates the conversion to fixed-width numbers. A proposed solution is a generic opcode capable of adjusting the number of bytes, which would either zero-pad or truncate the input as needed. However, truncation should only be successful if it eliminates zeroes, ensuring data integrity. For example, applying '4 FIXNUM' to an argument would produce a 32-bit little-endian number (LE32), while '8 FIXNUM' would result in a 64-bit little-endian number (LE64), and '32 FIXNUM' would generate a 256-bit number. This concept addresses the need for a versatile and consistent method to handle various numeric representations within code.