Byte Addressing for TypedArray views of heaps - why, and what does it accomplish? about validator HOT 4 CLOSED

The issue is that the typed arrays alias. Element 0 of the 32-bit heap aliases the same data as the first 4 elements of the 8-bit heap, etc. This is necessary for C and C++ compatibility, and luckily JS typed arrays are capable of it.

Given that aliasing, note that we can only read a 32-bit value at addresses 0, 4, 8, etc. - since the first element is bytes 0-3, second is 4-7, etc. In other words, the pointer must be aligned: 32-bit values are read from addresses that are a multiple of 32 bits.

The shift enforces that: a 32-bit read of ptr >> 2 means that we read from address ptr, but we force it to be aligned. If ptr is 4, then we read from element 1, which aliases bytes 4-7, etc. But if we try to do an unaligned read from 5, we also read from the same location, as the shift removes the unaligned bits.

from validator.

So it's behaving as if ptr were assumed to be a byte offset of a raw buffer, rather than an array index? So I can write my "pointers" as offsets like so and save myself a few characters:

...
var P_MYVAR = 0;
var P_MYVAR2 = 4;
...
heap32[P_MYVAR >>2] = ...

What's the advantage of doing it this way vs. just expecting the transpiler to do the math, compile-time performance? I guess people aren't expected to write this by hand very often.

from validator.

Yes, ptr is just like a C pointer - it's the actual address.

Doing the shift on each load/store ensures alignment as mentioned before. It also is efficient since when generating machine code you want the actual address, not the JS typed array index.

from validator.

Gotcha. Thanks for the help :)

from validator.