Does the D teams would like to increase the WASM support

[H. S. Teoh]

On Thu, Nov 17, 2022 at 10:49:32PM +0000, bioinfornatics via Digitalmars-d wrote:
[...]
> We all know that D can do wasm code through ldc compiler since years.
> But as the dev experience int so good it is still a toy/an
> experimental thing.
> 
> So I would like to know if Dlang aims to provides a better experience
> to code wasm ?

It will happen when one of us who wants it to move forward take things
into our own hands and write the code to make it happen.


> Indeed, currently we have to
> 1. use D mostly without object.d so it is close to use a D compiler to
> write C code.
> 2. wrap de code into some llvm statements
> 
> ```D
> // import a function "add" from module name "math" and rename it to
> "add_numbers"
> @llvmAttr("wasm-import-module", "math") @llvmAttr("wasm-import-name", "add")
> {
> 	int add_numbers(int a, int b);
> }
> ```

Here's my vision of how it should be: all of the above boilerplate
should be factored into compile-time templates that automatically wrap
around naturally-written D functions.  I.e., user code would write:

	import math;
	int my_code() {
		return add_numbers(1, 2);
	}

and the templates will automagically insert the rest of the boilerplate
for you.


> 3. Linux Distro user which use D though deb, rpm … have a shared
> phobos library how to put those symbol into the wasm in such case ?

I don't think WASM even has the concept of shared libraries at the
moment.  Each WASM module is essentially isolated in its own universe,
and interaction with the outside world requires Javascript glue code.

For the most part, the codegen shouldn't be a problem; most of Phobos is
templates anyway so the compiler will just instantiate and generate the
WASM code along with the calling user code.

However, for the shared part you pretty much have to either compile
Phobos into the user WASM module, or compile it as a separate module
that will then require Javascript glue code to bind together.  For
speed, I think the former would be preferable.


> 4. compiler triple parameters `-mtriple=wasm32-unknown-unknown-wasm
> -betterC`

One way to work around this is to write a WASM-specific object.d along
with various druntime hooks stubbed.  Not sure how we'd do the GC part,
though.


> So it would be really helpful that the compilers and Dlang get a
> better wasm support.

I think that goes without saying.


> 1. As to provides a wasm flag to the compiler to do some stuff
> 2. tags function `@wasm` or something else and any others thing that
> could turn the D wasm toy to something usable

Why wait for stuff to be added to the compiler?  We can move stuff along
now.  I envision two components to this: (1) a D template module that
you import and instantiate, which will auto-generate the @llvmAttr
boilerplate by introspection.  (2) a helper build script to automate
away the `-mtriple=...` stuff and auto-generate Javascript glue code for
moving stuff across the JS/WASM boundary.


[...]
> I would appreciate to get the point of views of D backend, `phobos`
> and `druntime` dev teams

I'm not holding my breath for anybody else to do anything.  Why not take
things into our own hands and write the code now?

(And BTW, I'm not part of any "dev team"; I'm just a random nobody who's
willing to write some code in his spare time to get things done.  I
write code to do things I want to do; if it happens to help the
community, then so much the better.)


> As references:
> * 2 years ago, yet! Adam provides some feedback to the D community: [D
> Tetris running on
> Webassembly](http://dpldocs.info/this-week-in-d/Blog.Posted_2020_08_10.html).
> * 3 years ago, Sebastian create the [spasm](https://github.com/skoppe/spasm)
> library
[...]

It will take someone who's motivated enough to do the work to get things
to move forward.  A lot of the foundational work is already there; now
it's just a matter of packaging it into a more user-friendly package.


T

-- 
Answer: Because it breaks the logical sequence of discussion. / Question: Why is top posting bad?