In WebAssembly what is the rationale for having both 32- and 64-bit numbers?

Viewed 422

WebAssembly has only four value types:

  • i32 – 32-bit integers
  • f32 – 32-bit floating point numbers
  • i64 – 64-bit integers
  • f64 – 64-bit floating point numbers

Each has their own set of opcodes representing arithmetic operations, e.g. i32.add, i64.add, f32.add and f64.add. There are also opcodes for wrapping narrower integers into wider types, e.g. int32.store_8, int64.load32_u. WebAssembly v1 defines ~170 opcodes of which ~70 are specifically for 32-bit numbers and ~75 are for 64-bit.

It seems to me that dropping support for 32-bit numbers would almost halve the number of opcodes without any loss of functionality. Which leads me to wonder: what is the benefit of having both?

There are some discussions around this on GitHub but they're a bit too technical for me.

2 Answers

They exists for much the same reason that many programming languages support numerics of varying precision - lower precision numbers require less storage and operations applied to these can be faster than for higher precision numbers.

Furthermore, reducing the number of opcodes in WebAssembly as suggested wouldn’t yield any tangible benefit. They always use a single byte for their storage.

One of WebAssembly’s goals is to efficiently run on widely used modern processors (including embedded systems), which all support 32-bit operations.

Related