search

ewasm / design

Ewasm Design Overview and Specification
Apache License 2.0
1.02k stars 125 forks source link

wasm256 - Wasm with native i256 #193

Open axic opened 5 years ago

axic commented 5 years ago

Depending on the speed of #189 we may want to consider augmenting Wasm with 256-bit support. This issue track the extreme end where native 256-bit opcodes are added.

These native opcodes could operate on memory or on stack.

Operating on memory

Only instructions would need to be introduced, such as i256.add, taking memory pointers. The drawback here is the overhead of accessing the memory.

Operating on stack

In this case load/store operations to move between stack and memory as well as operations on the stack items would be needed. Such as i256.load, i256.store and i256.add, etc.

The drawback here is that the entire stack would need to be 256-bit wide increasing the runtime memory usage and potentially the complexity.

Bringing in memory as stack

This would mean a special opcode maps a memory region as stack ("stack pointer"), similar to how x86 works.

Such as i256.setstack <memoryOffset>.

TBD

jakelang commented 5 years ago

Meh. I think we should focus fully on the bignum library. Augmenting the WASM spec has a lot of implications and resource requirements that we can't fulfill.