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.

Sign up for GitHub

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

Jump to bottom

Possible backends #156

Closed
pepyakin opened this issue May 20, 2019 · 4 comments
Closed

Possible backends #156

pepyakin opened this issue May 20, 2019 · 4 comments

Comments

@pepyakin
Copy link
Contributor

pepyakin commented May 20, 2019 •
edited
Loading

Now having the lightbeam backend being added, I am curious on what is the scope of this project. Will it be beneficial to add, say, wasmi backend (for ensuring correctness) or llvm for highly optimized builds?
@sunfishcode
Copy link
Member

Yes, interpreters and additional compiling backends are in scope.

I haven't looked at what a wasmi backend in particular might look like yet, and it's likely that wasmtime-runtime will need some changes to support this, but that's one of the places we're interested in heading.

kubkon pushed a commit that referenced this issue Nov 7, 2019
@sunfishcode
Make wasi-common's Error messages prettier. (#156)
9a5c53b 
Instead of returning the debug formatting, which includes the enum
names, like `Io(...)`, just run the formatting function of the inner
error objects, which is nicer for command-line use.
@ethanfrey
Copy link

Any update here?

I'm investigating switching to wasmtime as our wasm backend, and the cranelift AOT and light beam JIT pairs looks good. I did see a comment in the README about supporting interpreters and that would be nice for some situations, if we could swap that out so easily.

However, looking into the compiler strategies, it seems an enum of cranelift or light beam.

Am I correct that there is no wasm interpreter that works with wasmtime? And is there any tracking issue (besides this) with any plans? I would also be interested in wasmi support

@sunfishcode
Copy link
Member

Yes, you're correct. I don't think we have a separate tracking issue, though I do know there are a lot of people are interested in interpreter support.

@alexcrichton
Copy link
Member

Lightbeam was removed in #3390 as explained in RFC 14. I think we're still interested in new backends but they'll need to go through the RFC process, so I'm going to close this.

grishasobol pushed a commit to grishasobol/wasmtime that referenced this issue Nov 29, 2021
@arkpar @pepyakin
Fixed documentation for used_size (bytecodealliance#156)
073e4e7
pchickey added a commit to pchickey/wasmtime that referenced this issue May 16, 2023
@pchickey
Redesign wasi ctx a bit (bytecodealliance#156)
3e888f7 
* redesign wasi ctx and builder

* in ctx, resources are only ever owned by the table
* preopen dirs and stdio are just indexes into the table that we hand to the caller
* builder requires less boxing, in general, takes more impl traits

* tests: rewrite the way we generate tests to not construct store

* uncomment WasiCtx's pool methods
dhil added a commit to dhil/wasmtime that referenced this issue Apr 15, 2024
@dhil
Merge with upstream (bytecodealliance#156)
b783f55
avanhatt pushed a commit to wellesley-prog-sys/wasmtime that referenced this issue Oct 18, 2024
@mmcloughlin
isle: populate rule name map in sema (bytecodealliance#156)
009a9af 
Populate a `rule_map` in the `sema::TermEnv` mapping interned rule names
to rule IDs. This is similar to the `term_map` that already exists.

This should be useful in bytecodealliance#151 bytecodealliance#128 where we need to apply attributes to
rules.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
4 participants
@alexcrichton @pepyakin @sunfishcode @ethanfrey