You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Basic support for memory64 is finished(details can be found in this issue), and this issue is opened to track table64 extension support for memory64.
Overview
The core idea is straightforward, it's similar to memory64, in the table section, a table flag is to indicate whether it's the 64-bit table. If it is, the min and (optional)max entry size of that table can be i64, and the element index of that table is also i64.
Also, in all the related opcodes and element sections, the table element index will change to type i64 if it is accessing the 64-bit table.
Topics for Further Discussion
1. Should we allow the table to have an initial/maximum size greater than UINT32_MAX?
If we were to support large-size tables(number of entries > UINT32_MAX), the table instance data structure needs to be changed and therefore AOT ABI will need to change too. I also think it's relatively a corner case and it's a little impractical to have such a large table, it's not worth changing the AOT ABI for it. So my initial plan was to disallow it and report some error message in the loader.
The text was updated successfully, but these errors were encountered:
Basic support for memory64 is finished(details can be found in this issue), and this issue is opened to track table64 extension support for memory64.
Overview
The core idea is straightforward, it's similar to memory64, in the table section, a table flag is to indicate whether it's the 64-bit table. If it is, the min and (optional)max entry size of that table can be i64, and the element index of that table is also i64.
Also, in all the related opcodes and element sections, the table element index will change to type i64 if it is accessing the 64-bit table.
Topics for Further Discussion
1. Should we allow the table to have an initial/maximum size greater than
UINT32_MAX
?If we were to support large-size tables(number of entries >
UINT32_MAX
), the table instance data structure needs to be changed and therefore AOT ABI will need to change too. I also think it's relatively a corner case and it's a little impractical to have such a large table, it's not worth changing the AOT ABI for it. So my initial plan was to disallow it and report some error message in the loader.The text was updated successfully, but these errors were encountered: