Skip to content
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

Draft
wants to merge 3 commits into
base: main
Choose a base branch
from
Draft

Global Store #128

wants to merge 3 commits into from

Conversation

george-cosma
Copy link
Collaborator

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

  • Ran cargo fmt
  • Ran cargo check
  • Ran cargo build
  • Ran cargo doc
  • Ran nix fmt

Github Issue

This pull request closes <GITHUB_ISSUE>

@github-actions github-actions bot added the core label Feb 18, 2025
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 {
Copy link

@cemonem cemonem Feb 19, 2025

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

Copy link

@cemonem cemonem Feb 19, 2025

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
Copy link

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants