Proposal for porting D runtime to WebAssembly

Sebastiaan Koppe mail at
Sat Nov 23 16:14:35 UTC 2019

On Saturday, 23 November 2019 at 10:29:24 UTC, Johan Engelen 
> Perhaps you can explicitly clarify that "port" in this context 
> means that you will add the required version(WebAssembly) 
> blocks in the official druntime, rather than in a fork of 
> druntime.

Indeed. It will not be a fork, but the changes will be upstreamed 
into the official druntime.

> (WebAssembly predefined version now explicitly mentions that it 
> is for 32bit. Do you want to broaden this to 64bit aswell, or 
> add a new version identifier?)

I haven't seen anybody working on wasm64. I know it exists, but 
that is about it.

I do not know what the future of wasm64 will hold. Probably there 
will come a time somebody needs it, but as of yet everybody 
focuses on wasm32, and I don't see that changing anytime soon.

Still, I think it is a good idea to be prepared. Personally I 
would add wasm32 and wasm64 and also define WebAssembly whenever 
one of them is. Don't know if that is the smart thing to do.

> I read that Clang uses a triple with explicit mention of WASI: 
> --target wasm32-wasi
> Are you planning for the same with LDC? Will you need a new 
> predefined version identifier for WASI-libc? Perhaps group all 
> required compiler features in a section (and move the `real` 
> story there).

Rust uses that as well. It would make sense for us to use that as 
well. Good idea.

The ultimate goal is to not use libc, but directly call the wasi 
api. In the mean, yes, we should introduce the WASI-libc version. 
I have now put all that under the WebAssembly version, but that 
is conflating things. (although it is not a big deal, since the 
linker will strip them out if unused.)

Will add to a separate compiler section in the gist.

> Can you elaborate on how you envision CI testing?

We can use any of the WASI runtimes. I personally use Wasmer 
(written in rust, uses cranelift which is also used in Firefox). 
Another option (or in parallel) would be using the V8 in either 
node or an headless browser (although that would be better suited 
for testing JavaScript interoperability).

I would go with wasmer first.

> Do you want to add that to LDC testing? (this may also mean 
> that you first add a new change to LDC's druntime, confirming 
> functionality with LDC CI, and then upstreaming the change)

Yes, in fact, I am already targetting LDC's druntime.

> I'm assuming you already started some work in this area? Where 
> can we track it?

Will post the link here after some clean up. A few days.

> Great initiative!
>   Johan

Thanks, these are some very good points.

More information about the Digitalmars-d-announce mailing list