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

WASM Support: Enhance @extern for Module-Qualified Imports #1305

Closed
humbletim opened this issue Aug 4, 2024 · 6 comments
Closed

WASM Support: Enhance @extern for Module-Qualified Imports #1305

humbletim opened this issue Aug 4, 2024 · 6 comments
Assignees
Labels
Accepted Accepted Request Enhancement Request New feature or request Implemented Needs Verification Check if this issue is resolved
Milestone

Comments

@humbletim
Copy link

This issue proposes an enhancement to the C3 compiler's @extern directive to support importing functions from WebAssembly (WASM) frameworks like WASI, which use module-namespace qualified import symbols.

Currently, C3 effectively treats the module namespace as hard-coded to "env". While this allows for @extern("fd_write") to become env => fd_write, it doesn't support importing functions like wasi_snapshot_preview1 => fd_write.

Proposed Solution:

Extend the @extern directive to accept a module name along with the function name. Two potential approaches are:

  1. Encoded String: Keeping with C3's existing aesthetic, the @extern directive could accept an encoded string containing both parts. For example, @extern("wasi_snapshot_preview1%fd_write") would map to wasi_snapshot_preview1 => fd_write during the LLVM processing stage. The % character would trigger the separation of the string into module and function names.

  2. Separate Arguments: Alternatively, the directive could accept separate arguments for the module and function names. This approach might be more explicit: @extern("wasi_snapshot_preview1", "fd_write").

Collaboration:

This issue aims to gather feedback and discuss potential implementation strategies. If others become interested in this feature, I'd be happy to collaborate on a pull request (PR) to implement the chosen solution.

References:

  • Godbolt Example demonstrating Clang C/C++ __attribute__((import_module("ns"))) behavior:
  • Potential LLVM Integration Point:
    • if (decl->is_extern && arch_is_wasm(platform_target.arch))
      {
      scratch_buffer_set_extern_decl_name(decl, true);
      llvm_attribute_add_string(c, function, "wasm-import-name", scratch_buffer_to_string(), -1);
      }
@lerno
Copy link
Collaborator

lerno commented Aug 4, 2024

Separate arguments is a good idea, since it could just default to "env" for the 1 argument version.

@lerno
Copy link
Collaborator

lerno commented Aug 5, 2024

Would you like to try contributing this?

@lerno
Copy link
Collaborator

lerno commented Aug 7, 2024

Ping @humbletim

@humbletim
Copy link
Author

Would you like to try contributing this?

Thanks for the ping! I'm definitely interested in contributing to a solution. I believe I have a good grasp of where the c3 code could be modified to accommodate the new llvm attribute. However, I'll need to do some more digging to fully understand the extern directive and potential code generation changes.

If you've already outlined a solution, I'm happy to help test it out as well.

@lerno
Copy link
Collaborator

lerno commented Aug 9, 2024

My main question is whether to retain the @wasm tag and just make it work like @export but also take this second parameter. Or use @export for it, even though it doesn't make sense for other targets (I think?)

@lerno
Copy link
Collaborator

lerno commented Aug 25, 2024

Ping!

@lerno lerno added this to the 0.6.3 milestone Sep 14, 2024
@lerno lerno added Enhancement Request New feature or request Accepted Accepted Request labels Sep 20, 2024
@lerno lerno self-assigned this Sep 24, 2024
@lerno lerno added the In Progress This task is currently being worked on label Sep 24, 2024
@lerno lerno added Implemented Needs Verification Check if this issue is resolved and removed In Progress This task is currently being worked on labels Sep 24, 2024
@lerno lerno closed this as completed Oct 3, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Accepted Accepted Request Enhancement Request New feature or request Implemented Needs Verification Check if this issue is resolved
Projects
None yet
Development

No branches or pull requests

2 participants