-
Notifications
You must be signed in to change notification settings - Fork 503
Tweaks and fixes to Memory64 proposal #1839
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
Conversation
|
Thanks @rossberg for looking into this. I had been meaning to ask you to go through some of the interpreter changes (since some of them I make while resolving conflicts and I think where unreviewed), but you beat me to it. I do think for the sake of keeping the history of this proposal in one place it might me good to land these changes in the memory64 repo before merging. Is that what you mean by "Feel free to upstream back to the repo as you see fit"? I'm happy to do that. |
bvisness
left a comment
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.
All looks good to me!
document/core/exec/instructions.rst
Outdated
| 5. Let :math:`\X{mem}` be the :ref:`memory instance <syntax-meminst>` :math:`S.\SMEMS[a]`. | ||
|
|
||
| 6. Let :math:`\X{at}~\limits` be the :ref:`memory type <syntax-memtype>` :math:`\X{mem}.\MITYPE`. | ||
| 6. Assert: due to :ref:`validation <valid-load-extend>`, a value of :ref:`adress type <syntax-addrtype>` :math:`\X{at}` is on the top of the stack. |
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.
Typo: adress
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.
Fixed.
Yes, sounds good! |
Split out from WebAssembly/spec#1839
Interpreter: - Fixed evaluation of v128 load/store instructions to work with i64 - Reworked bulk operation execution to still reduce to well-typed instructions for i32 - Added missing size check to table allocation - Various minor refactorings and clean-ups Tests: - Added tests for size check in i64 table and memory type limits Split out from WebAssembly/spec#1839
Split out from WebAssembly/spec#1839
- Removed unnecessary/mismatching lookup of table/memory type in execution prose - Added missing result type lookup in formal rule for table.size and memory.size - Fixed computation of -1 result value for table.grow and table.size to work for i64 - Some fixes around specification of text format for inline elements/data shorthand - Fixed matching rules for tabletype/memtype to enforce same address type Split out from WebAssembly/spec#1839
Interpreter: - Fixed evaluation of v128 load/store instructions to work with i64 - Reworked bulk operation execution to still reduce to well-typed instructions for i32 - Added missing size check to table allocation - Various minor refactorings and clean-ups Tests: - Added tests for size check in i64 table and memory type limits Split out from WebAssembly/spec#1839
|
I think all these changes have now landed downstream in the memory64 repo |
Interpreter: - Fixed evaluation of v128 load/store instructions to work with i64 - Reworked bulk operation execution to still reduce to well-typed instructions for i32 - Added missing size check to table allocation - Various minor refactorings and clean-ups Tests: - Added tests for size check in i64 table and memory type limits Split out from WebAssembly/spec#1839
In preparation for merging the proposal to the wasm-3.0 branch, this PR fixes various smaller issues I discovered when going through the diffs for the merge.
Spec:
table.sizeandmemory.sizetable.growandtable.sizeto work for i64Interpreter:
Tests:
@sbc100, PTAL. Feel free to upstream back to the repo as you see fit.
Also, it would be good if you could add some tests for SIMD load/stores on i64 memories, since those were broken in the interpreter.