Proposal for porting D runtime to WebAssembly

Sebastiaan Koppe mail at skoppe.eu
Tue Jan 7 08:15:39 UTC 2020


On Saturday, 4 January 2020 at 16:28:24 UTC, kinke wrote:
> On Friday, 3 January 2020 at 10:34:40 UTC, Sebastiaan Koppe 
> wrote:
>> You can track the work here: 
>> https://github.com/skoppe/druntime/tree/wasm
>
> I gave it a quick glance; looks pretty good, and like pretty 
> much work. ;) - Thx.

Great. Thanks for looking.

> The compiler should probably help a bit by firstly predefining 
> a version `CRuntime_WASI` (either for all wasm targets, or for 
> triples like wasm32-unknown-unknown-wasi) and secondly emitting 
> TLS globals as regular globals for now, so that you don't have 
> to add `__gshared` everywhere.

Yes. I will probably manage to do the first, but for the second 
one I definitely need some pointers.

>> - reals (probably are going to be unsupported)
>
> It's probably just a matter of checking which type clang uses 
> for C `long double` when targeting wasm, and making LDC use the 
> same type.

Could be. I personally prefer to avoid them because wasm only 
supports f32/f64, which I guess means they will be emulated (I 
have no idea though, maybe some wasm hosts do the right thing). 
But some people might need them, so if fixing the ABI is not a 
big deal, we could include them.

>> - wasi libc needs to be distributed (either in source and 
>> compiled into wasm druntime) or statically linked
>
> I'd prefer a static lib (and referencing that one via 
> `-defaultlib=druntime-ldc,phobos2-ldc,wasi` in ldc2.conf's wasm 
> section).

Good.

> Building it via LDC CI for inclusion in (some?) prebuilt LDC 
> packages is probably not that much of a hassle with a clang 
> host compiler.

I don't think so either. I have already got it building, so I 
just need to go over my notes.

>> once ldc-build-druntime works
>
> If you need some CMake help (excluding C files etc.), 
> https://github.com/ldc-developers/ldc/pull/2787 might have 
> something useful.

Thanks.

>> (_start is the wasm's equivalent of _Dmain)
>
> Not really; _start (in libc) is used on Linux too, which sets 
> up the C runtime, then calls C main, which calls druntime's 
> _d_run_main which in turn calls _Dmain.

Ahh, fumbling as I go along. Thanks for the correction.


More information about the Digitalmars-d-announce mailing list