8000 Support for web assembly? · Issue #47 · zetzit/zz · GitHub
[go: up one dir, main page]
Skip to content
This repository was archived by the owner on Jun 17, 2022. It is now read-only.
This repository was archived by the owner on Jun 17, 2022. It is now read-only.

Support for web assembly? #47

Open
Open
Support for web assembly?#47
Labels
questionFurther information is requested

Description

@richardanaya
richardanaya
opened on Apr 1, 2020

Hey, I'm a big fan of Rust, one of the reasons why I keep going back to it is they have amazing support for web assembly compilation. So does C with llvm! I think there's many devs out there who want a better language for web assembly, but C is pretty brutal. I've found myself looking for a good C trancompiled language for awhile, but none of them seem interested in making web assembly a first candidate target. Anyhow, I find ZZ interesting as a Rust dev who loves web assembly, and I would love to see a language like this compete as an alternative in that space.

Some thoughts I have for ZZ that would make it really appeal to web assembly devs (who tend to be javascript fanatics )

  • a package manager that makes installing dependencies easy
  • a more narrower standard library that basically only does memory allocation (since that's all wasm has access to) and wasm size is important ( think no_std + alloc )
  • easy command support so that a dev could compile .zz with a simple one line command that uses maximum optimization for wasm for reducing file size
  • one binary distributions for popular environments (windows, osx, linux )
  • an easy way to do #define export __attribute__((visibility("default")))
  • support for way better macros that can do things like construct json structures

I sometimes program web assembly in non-Rust languages, and I've created a fairly mature library that acts as a bridge between web assembly and the browser dom that is fairly technology agnostic.

This tech could accelerate zz in the web assembly space greatly. Here's an example of a hello world:

#include "../../js_ffi.h"

export int main() {
	int log = jsffiregister("window.alert");
	jsfficall1(JS_UNDEFINED,log,TYPE_STRING,(JSValue)(int)&"Hello World!");
	return 0;
}
clang -O3 --target=wasm32 -nostdlib -I./ -Wl,--no-entry -Wl,-allow-undefined -Wl,--export-dynamic -o main.wasm src/main.c

Activity

  1. aep commented on Apr 1, 2020

    @aep
    aep
    on Apr 1, 2020
    Collaborator

    thank you so much for the suggestion! i did not realize how much that is a match made in heaven, before you asked.

    a package manager that makes installing dependencies easy

    high up my list, but have to fix some bugs first

    a more narrower standard library that basically only does memory allocation (since that's all wasm has access to) and wasm size is important ( think no_std + alloc )

    accidentally zz scores all points here because it is completely heap free. there is no separate no_std which has consistently been my main critique with rust. the entire language is built around convenient use of stack scoping, allocating 0 bytes dynamic memory. It should in theory perform better than C++ (and obviously rust)

    binary sizes of zz are insane too. devguard carrier was 5mb with rust and is now 80kb with zz.
    thats an entire ssh and http2 server.

    easy command support so that a dev could compile .zz with a simple one line command that uses maximum optimization for wasm for reducing file size

    zz already builds nodejs modules. easy to add wasm.

    one binary distributions for popular environments (windows, osx, linux )

    of course

    an easy way to do #define export attribute((visibility("default")))

    thats the builtin export keyword :)
    zz has a bunch of stuff built in that is a natural fit to exporting clean ABIs

    support for way better macros that can do things like construct json structures

    i just merged proc macros, which will enable something like serde.

    Here's an example of a hello world:

    i like this. where can i find more about it?

  2. richardanaya commented on Apr 1, 2020

    @richardanaya
    richardanaya
    on Apr 1, 2020
    Author

    oops, forgot to post the link! https://github.com/richardanaya/js_ffi/

  3. jwerle commented on Apr 25, 2020

    @jwerle
    jwerle
    on Apr 25, 2020
    Member

    I was able to compile a hello world in release mode and run it with wasmer with the clang from the wasi-sdk by running:

    $ mkdir zz-wasm
$ cd zz-wasm
$ zz init
$ CC=/opt/wasi-sdk/bin/clang zz build --release
$ wasmer ./target/release/bin/zz_wasm
hello zz-wasm

  4. jwerle commented on Apr 25, 2020

    @jwerle
    jwerle
    on Apr 25, 2020
    Member

    With node@14, it can be loaded with wasi:

    const { WASI } = require('wasi')
const fs = require('fs')

const wasi = new WASI(process) // argv, env
const buffer = new Uint8Array(fs.readFileSync('./target/release/bin/zz_wasm'))

WebAssembly.instantiate(buffer, {
  wasi_snapshot_preview1: wasi.wasiImport
})
  .then
DCE9
(onwasm)
  .catch(onerror)

function onerror(err) {
  console.error(err)
}

function onwasm(wasm) {
  wasi.start(wasm.instance)
}

    ran with:

    node --experimental-wasi-unstable-preview1 example.js

  5. jwerle commented on Apr 26, 2020

    @jwerle
    jwerle
    on Apr 26, 2020
    Member

    a more concrete example, with tail binding usage:
    https://github.com/zx-project/wasm-lib-hello-world

  6. aep commented on May 2, 2020

    @aep
    aep
    on May 2, 2020
    Collaborator

    nice. what do you think we should be part of zz? the build settings probably at least

  7. jwerle commented on May 2, 2020

    @jwerle
    jwerle
    on May 2, 2020
    Member

    We should probably figure out a way to emit WASM targets or allow users to configure library target names

    I put together another example here: https://github.com/little-core-labs/base64-wasm

  8. aep commented on May 2, 2020

    @aep
    aep
    on May 2, 2020
    Collaborator

    woa thats a really nice example.
    ideally i'd want to be able to build the entire thing with zetz, since already does have an npm module target, but currently a target can't depend on another target, so that's something i need to figure out first

  9. jwerle commented on May 6, 2020

    @jwerle
    jwerle
    on May 6, 2020
    Member

    yeah this example was intended to show a ZZ implementation of Base64 that can compile to WASM format, and be used in an environment that can load and execute WebAssembly. The path with the least resistance is node.js. Ideally, I can write in ZZ, compile as usual, but know that I can compile to WASM as well. Having WASM as a compilation target just means I need to know if my module or any other ZZ modules I consume intended on using syscalls requiring a WASI.

    More here too:
    https://github.com/little-core-labs/hyperid-wasm
    https://github.com/little-core-labs/varint-wasm

    Overall, WASM is slow and limiting, but nice to have as a compile target

  10. jwerle commented on May 6, 2020

    @jwerle
    jwerle
    on May 6, 2020
    Member

    when you say target depending on another target, do you mean one zz module depending on the built library of another?

  11. aep commented on May 6, 2020

    @aep
    aep
    on May 6, 2020
    Collaborator

    nah, there's currently no way the nodejs target can include a wasm binary because they're built in parallel

  12. jwerle
    added
    questionFurther information is requested
    on Jul 25, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    questionFurther information is requested

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions
      0