-
-
Notifications
You must be signed in to change notification settings - Fork 671
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
Compile to asm.js #2869
Comments
Isn't wasm the successor to asm.js? Is there more background to support asm.js instead of using wasm? |
@listepo I would recommend using Binaryen's `wasm2js` as demonstrated by that comment. If it's tedious to integrate an external native tool into your project's build requirements, there should already be a Wasm-compiled version available after installing AS, via `npx wasm2js` (or just `wasm2js` in a `package.json` script). I don't remember if that functionality is broken though...
|
This will emit JavaScript
This will cache the JavaScript representation of the file that Deno executes
Node.js has built in strip types, and can execute AssemblyScript directly with |
That's not the same thing as compiling to asm.js, because it prevents the usage of AS-specific features and may not have the same performance, depending on the code. The author was specifically interested in Static Hermes, and your approach wouldn't be particularly useful (they're already able to execute JS). Still, asm.js is becoming less and less useful by the day, so there's no sense in supporting it when |
Yes, it is. There's no way you can tell the difference between the input or output of Static Hermes compiled to native executable, Static Hermes with I've compiled the same algorithm using each of the above. You cannout blind test pick which is which. |
If you're able to do all of those, then there's no semantic difference (maybe a performance difference but idk). However, if you use AS-specific features ( |
That's a technically incorrect assumption.
Bun also executes
That's directly executing AssemblyScript source code.
That winds up looking something like this, depending on the runtime that strips or transforms the types
or this
or this
Using WASM compiled from JavaScript with Javy (depends on QuickJS Rust crate)
Static Hermes with
I don't think there is any way for you to accurately pick which JavaScript engine or WebAssembly engine, or native executable, nor AssemblyScript, nor TypeScript, nor JavaScript is which given the initial commitment to write the same algorithm in an agnostic manner. I invite you to accurately discern based on any criteria you set out in writing, which runtime or native executable is executing the given algorithm with input as arguments or from Sources:
|
Re
We have the technology, we can figure that out. Just write out the candidates, the test parameters, and so forth. Bytecode Alliance Javy, AssemblyScript, Hermes and Static Hermes can be compiled to WASM - essentially using JavaScript source code. Each supports WASI. Node.js is slowest running TypeScript directly TypeScript .ts file execution benchmarks for Deno, Bun, Node.js. My interest is in using JavaScript as source code for cross-compilation. That requires a lot of testing in various runtimes, engines, and testing cross-compilation to native executable, WASM, and other programming languages. I think TypeScript is sold in part as a "superset" of JavaScript, thus AssemblyScript must be capable of being compiled or tranpsiled or transformed or stipped of types if you prefer - to JavaScript - by any means necessary. |
I conceded that if you're able to use your AS code on those runtimes (i.e. your code is completely compatible with TypeScript/JavaScript concepts), then you'll observe no semantic difference. However, if you have code like the following example, it won't work: const LENGTH = 1024
const scratch = memory.data(LENGTH)
store<i32>(1, 1, scratch)
for (let i = 2; i < LENGTH; i++) {
store<i32>(
i,
load<i32>(i - 1, scratch) + load<i32>(i - 2, scratch),
scratch
)
} (The example isn't exactly representative of a real-world scenario, but here's something in the wild that won't work with your approach) |
You might also be interested in Porffor...they definitely have JS spec compatibility as their primary goal.
AS is supposed to seem familiar to web devs; it doesn't provide strict JS/TS compatibility guarantees. If you want, you can try to polyfill AS-specific behavior, but it'll be difficult to deal with things like |
I think that particular example is based on how you have written
So we get this
when executing this
I'm not opposed to using
Already did that, here to extend
Either the AssemblyScript Portable documentation is true and correct
or not. If true and correct that
Tried that code. Javy, Static Hermes do what they say they do. |
There is. It works
The output at the end looks like this
Here is how I use that resulting JavaScript with WASI support
Execute
|
Can't The question to me becomes why not write the AssemblyScript-specific functions and objects in source code in such a way that it can compile in it's entirety to both WASM and JavaScript? |
It's not the priority of many (perhaps most) users. AS is used because it's familiar, simple, and performant. Anyways, we're derailing this issue. |
@CountBleck So what's the verdict here? Use The only AssemblyScript-specific "features" are The "performant" claim requires numbers. Otherwise it's just an empty claim. "performant" compared to what? Where are the numbers? |
Feature suggestion
It would be nice to be able compile to asm.js
The text was updated successfully, but these errors were encountered: