Arne Vogel (Feb 18 2025 at 05:48): Arne Vogel (Feb 18 2025 at 05:48):Hi,
I am handwriting wit at the moment, and I found that store instructions write more than the value I want to store. E.g.,
> 0
> 956301312
> 87621632
> 342272
> 1337
> 5
> 0
Is the result of this program
(module
(import "console" "log" (func $log (param i32)))
(memory 2)
(func $main
i32.const 4
i32.const 1337
i32.store
i32.const 0
i32.load
call $log
i32.const 1
i32.load
call $log
i32.const 2
i32.load
call $log
i32.const 3
i32.load
call $log
i32.const 4
i32.load
call $log
i32.const 5
i32.load
call $log
i32.const 6
i32.load
call $log
)
(start $main)
)
(run on https://developer.mozilla.org/en-US/docs/WebAssembly/Reference/Memory/Size)
I haven't found any explanation for this behaviour. Is there any documentation for this?
Also, bonus question: given a memory dump, how can I restore the memory from scratch without knowing which stores/memory.fills were used? Because how could I be sure the number is intended and not one of those "additional" ones?
1476406020
22544427
956389376
20513112
-1845413631
9568569
-1040150015
96600210
-1694121472
26936770
1124178693
37945755
1174553345
21365315
-167688702
100008262
390657
1526
5
0
0
0
385875968
1507328
5888
23
134217728
524288
2048
8
67108864
262144
1024
4
402653184
1572864
6144
24
0
0
268435456
1048576
100667392
393232
1536
6
318767104
1245184
268440320
1048595
184553472
720912
2816
11
This program only stores the 1337 value, at byte offset 4. i32.load's operand is a byte offset, and not an index into an i32 array. Those loads are 4-byte loads at byte offsets 0, 1, 2, 3, etc. are seeing the bytes of the stored 1337 effectively shifted into different positions.
Last updated: Feb 28 2025 at 01:30 UTC