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

Migrate the frontend to use the new HIR2 #363

Open
greenhat opened this issue Dec 17, 2024 · 1 comment
Open

Migrate the frontend to use the new HIR2 #363

greenhat opened this issue Dec 17, 2024 · 1 comment
Assignees

Comments

@greenhat
Copy link
Contributor

Compiled notes from PR comments:

anon namespace

Rather than using the Anon namespace, we should translate symbol names as described in the Component Translation discussion. The gist is that the WIT package name becomes the LibraryNamespace (specifically the User variant), sans version, items exported from the component use the export name as the first non-namespace path component, and so on (i.e. functions exported from an exported interface are additional components). Future changes to LibraryPath will make the syntax for fully-qualified paths a bit more like WIT identifiers, but for now the main thing we want to do is translate them in a way that retains useful semantics in Miden Assembly. We've largely already discussed this, but I'm just reiterating it here since it is relevant to decisions documented in this PR
Likewise, the way in which module/function names are recovered I believe will need to be changed, but we can do that when merging the new IR into the frontend. This is also described in the Component Translation discussion, but essentially we can recover the original WIT interfaces (and their names/exports) using the component instances exported from the top-level component

from #353 :

Generate synthetic functions for Wasm CM canon lift/lower in the frontend

See #357 comments for more details.

@bitwalker
Copy link
Contributor

Here's another comment that you may find useful, that more clearly defines ABI and calling convention terminology, and how I envision us approaching those concepts in the compiler.

Essentially, ABI details are largely implicit, and only relevant during code generation. Calling convention details are defined in terms of the ABI, and are also largely irrelevant until code generation, except in terms of validation (i.e. that function signatures are valid according to their assigned convention), and to the extent that they are used to derive other information (e.g. function calls to a CanonLift function must be performed using call rather than exec). We do not need to explicitly encode ABI details in the IR anywhere.

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

No branches or pull requests

2 participants