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

Initial stab at porting asm/stack.ts to Rust #752

Closed
wants to merge 302 commits into from

Conversation

alexcrichton
Copy link

This commit is an initial stab at adding some Rust to glimmer, notably to
implement some bits-and-pieces of the low-level package for now. Specifically
this commit takes the Stack type in the low-level module and ports it to
Rust and then integrates it all back with WebAssembly.

Some notable points of this:

  • The error handling isn't great right now and the interface may not be quite
    right just yet.
  • Right now the raw wasm instructions are used to allocate memory (the Rust
    standard library's allocator is avoided) and internally a freelist is
    maintained of free'd pages.
  • Currently memory is never deallocated in Rust which means that pages are
    forever in use and usage will "grow without bound". Eventually a manual call
    to "free this" will need to be inserted for the Stack type.

#![feature(link_llvm_intrinsics)]

#[no_mangle]
pub extern fn add(a: u32, b: u32) -> u32 {

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

was this intended to be left in?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🤔

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Oops yeah that was just leftover

@alexcrichton
Copy link
Author

The three currently failing tests I believe are

  • SL_IE_11 - I think that IE doesn't have WebAssembly support at all?
  • SL_Safari_Last - I think this is using Safari 10 which according to this support was added in Safari 11.
  • SL_MS_Edge - This looks to be Edge 15 but according to this the webassembly support is behind a flag by default? I tested with what I think is Edge 16 locally and it worked by out-of-the-box.

@jonnii
Copy link

jonnii commented Dec 2, 2017

Is the idea that you'll be able to have pluggable backends within glimmer-vm?

@alexcrichton
Copy link
Author

@wycats ok I pushed up the extra commits we talked about here! I think I addressed most of the immediate feedback and left a few questions, but let me know if there's anything else that should be resolved!

@chicoxyzzy
Copy link

@alexcrichton just in case, I can assure you that this table of wasm support by browsers is absolutely accurate https://caniuse.com/#feat=wasm

@wycats
Copy link
Contributor

wycats commented Jan 6, 2018

@chicoxyzzy confirm!

Should hopefully get further on CI!
The QUnit tests should now properly only start when the framework is loaded, and
otherwise an extra level of indirection was needed to ensure that once wasm
bindings were loaded they propagated correctly throughout the system.
Hopefully high-paced development is now over!
We don't want to accidentally use libstd abstractions too unnecessarily just yet
as they may bring in too much code size.
This is a helper defined in the `wasm_bindgen` crate for if we need it, which we
may!
This moves the interface and various imports over to using the `wasm_bindgen!`
macro. This enables a few nice features:

* Less duplication all over the place when adding a method, now you just add it
  then call it from JS.
* Ability to pass JS objects "through Rust" in a way that removes a bunch of
  globals/wrappers on the JS side of things.
* Hopefully more type safety and type checking long-term heading off bugs before
  they start to arise.
This also removes the `asm/stack.ts` file in favor of just going through the
original `LowLevelVM` itself
Due to recursive usage patterns it's not always possible, but if we can use it
then it's more efficient
alexcrichton and others added 20 commits March 9, 2018 07:59
This way we should cros the JS <-> wasm boundary hopefully a little less often.
Hopefully that'll get it to optimize *even more*, or at least that's the idea
The wasm-bindgen pass may remove functions and modify data (currently), so be
sure to run wasm-opt afterwards to get maximal optimizations and space savings.
For example dropping the wasm-bindgen statics drops the file size from 48k to
21k with this!
remove for of usage causing problems with upstream build
Switch one instance of zero-initialization to not zero-initializing as well to
save some perf
@lifeart
Copy link
Contributor

lifeart commented Jul 9, 2018

is it alive?

@cbou
Copy link

cbou commented Aug 23, 2018

Any news here?

@wycats
Copy link
Contributor

wycats commented Aug 27, 2018

It's somewhat alive, but we've been focusing our efforts on Ember integration lately. @chriskrycho is taking a stab at porting the compiler to Rust/wasm with some very promising results so far!

@kripken
Copy link

kripken commented Oct 29, 2019

Was this completed, or abandoned? Either way it would be interesting to hear some details of the experience here!

@Becavalier
Copy link

Is there any update regarding the VM migration to Wasm?

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

Successfully merging this pull request may close these issues.

None yet