| |
 | Posted by H. S. Teoh
in reply to bioinfornatics |  Permalink Reply |
|
H. S. Teoh 
Posted in reply to bioinfornatics
| 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?
|
