-
Notifications
You must be signed in to change notification settings - Fork 716
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
wasm proposal memory64 #2964
base: master
Are you sure you want to change the base?
wasm proposal memory64 #2964
Conversation
Hello, I am a code review bot on flows.network. Here are my reviews of code commits in this PR. Commit 3665603f934b4ac12298887afdcdefd7599f8682The pull request titled "wasm proposal: memory64" contains changes pertaining to the introduction of 64-bit memory support for WebAssembly. Here are the key changes identified in this pull request:
Potential problems:
|
0x02U, // Unknown limit type | ||
0x08U, // Unknown limit type |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
0x00 n:u32 ⇒ i32, {min n, max ϵ}, 0
0x01 n:u32 m:u32 ⇒ i32, {min n, max m}, 0
0x02 n:u32 ⇒ i32, {min n, max ϵ}, 1 ;; from threads proposal
0x03 n:u32 m:u32 ⇒ i32, {min n, max m}, 1 ;; from threads proposal
0x04 n:u64 ⇒ i64, {min n, max ϵ}, 0
0x05 n:u64 m:u64 ⇒ i64, {min n, max m}, 0
0x06 n:u64 ⇒ i64, {min n, max ϵ}, 1 ;; from threads proposal
0x07 n:u64 m:u64 ⇒ i64, {min n, max m}, 1 ;; from threads proposal
e2c15ae
to
5aafbbe
Compare
4b5d70b
to
30eb26e
Compare
This comment was marked as resolved.
This comment was marked as resolved.
5aafbbe
to
c63db49
Compare
482068e
to
c28d9ea
Compare
Update status
The status of linux is interesting, since I don't I touch any platform specific program. |
08bc089
to
a7c4a28
Compare
54be59d
to
7f2f73e
Compare
e3a795c
to
da5de5a
Compare
a7c4a28
to
daa9e95
Compare
da5de5a
to
f4ad197
Compare
daa9e95
to
53bedbf
Compare
* loader * limits encoding changes * `MemType` missing index type setup * assuming default is 32 mode * changes related values to uint64_t * validator * introduce helper `getItValueType` to do index type checking (index type is a new concept that introduced in the proposal, stands for indexing type for memory modes, memory64 use I64 and default is I32) * type check * store/load instructions * atomic instructions * v128 instructions * page count is possible up to 64-bit now * offset is 64bit now * execution * share more code for 32/64-bit mode * update related memory instructions * instruction load/store and load/store many * instruction atomic * driver: add option * stack manager: move `popIndexType` that pop value based on index type (refers to above description) * spec test * use `wasm-dev` branch to enable memory64 test suites * fix `wasmedgeExecutorCoreTests` by fixing the `grow` instruction * fix memory limit test (32-bit mode testing) Later fixup * fix bus error, overflow problem The root cause is combined from two trouble 1. In executor check we only check the offset didn't overflow by using maximal of uint64_t to substract it 2. In memory check we assume `const uint64_t AccessLen = Offset + Length` will not overflow! but the first check didn't ensure the second won't happen, thus, the error occurs. * fix `f32.load` If `ValVariant` stores `uint32_t` then must use `uint32_t`, but I use `uint64_t` and cause the problem. `valToIndex` now will judge index type of memory64 mode, then use the correct type to expand `ValVariant`. * fix windows build Signed-off-by: Lîm Tsú-thuàn <[email protected]>
53bedbf
to
3665603
Compare
resolve #2779