`ArrayBuffer` objects

[Jesús Leganés-Combarro]

Feature Request

Overview

Add support for ArrayBuffer objects. Being low level enough, they should be easy to implement, and would make it easier to build on top other things like strings or Buffer objects.

Impact

Small - UInt32Array, UInt64Array, Int32Array and Int64Array objects would be almost one-to-one with directly mapping some memory region in WebAssembly.
Medium - Other ArrayBuffer would need some calcs for the address and data masking, but doing them by hand or by a regular compiler would be done the same way too, so it would be mostly "optimal" code.

Details

It's low level enough and would be mostly mapping some memory region because WebAssembly to be compatible with ArrayBuffer objects, and also they are typed, and they would be used as building block for higher level for other objects like Strings, Buffers, HashMaps...

Due Date

2018-04-11

[Arthur Buldauskas]

It's unlikely, at least in the near/medium term that this will be implemented. It's not necessarily difficult but the effort level is low compared to the reward here.

I've exposed native load/store methods already provided by WebAssembly recently. These will eventually be documented, but here is an example of these in one of the self-hosted specs

walt/packages/walt-compiler/src/__tests__/native-opcode-spec.walt

Lines 39 to 45 in 17df62a

 function test16BitUnsigned(): i32 { 
   i32.store(0, 0x80008000); 
   const x: i32 = i32.load16_u(0); 
   // offsets are BYTE offsets not half-words. Same thing for i32s/i64s 
   const y: i32 = i32.load16_u(2); 
   return y + x; 
 } 

For now, I think it's enough to say that the native methods already provide the tools necessary to build more complex/higher level objects you mentioned.

I'm going to close this issue, but thank you for the suggestion.

[Jesús Leganés-Combarro]

the native methods already provide the tools necessary to build more complex/higher level objects you mentioned

This is just enough for me, thanks :-)