-
Notifications
You must be signed in to change notification settings - Fork 4
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
Global Store #128
base: main
Are you sure you want to change the base?
Global Store #128
Conversation
for function_idx in 0..self.modules[module_idx].functions.len() { | ||
let fn_store_idx = self.modules[module_idx].functions[function_idx]; | ||
let func: &FuncInst = &self.functions[fn_store_idx]; | ||
if let FuncInst::Imported(import) = func { |
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.
global stores might be completely relieving us from Imported/Local enums. Also it might be better to do instantiations after verifying imports and determining values of const exprs within initialization, the spec orders them in that way here if i understand correctly https://webassembly.github.io/spec/core/exec/modules.html#alloc-module
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.
One more thing is, it might be beneficial to check whether something imported from Y in module X is certainly exported in module Y, by just going over the exports of Y here, so essentially a double for loop going over X's import section in the outer and Y's export section in the inner. Or if there is an issue of 100 exports (i don't think this is worrisome) on the Y's end, simply a hashmap that holds (module,name) pairs as keys with the store address of the imported instance as values (imported function, global, etc.)
ty: *ty, | ||
locals, | ||
code_expr, | ||
// TODO figure out where we want our sidetables |
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.
Sidetables would ideally be a field of modules, and would be per-module with along with their source code. In our current implementation we still have them per function, they can stay this way for now
Pull Request Overview
This pull request adds/changes/fixes...
Testing Strategy
This pull request was tested by...
TODO or Help Wanted
This pull request still needs...
Formatting
cargo fmt
cargo check
cargo build
cargo doc
nix fmt
Github Issue
This pull request closes <GITHUB_ISSUE>