DMD Frontend working in WebAssembly

hatf0 harrison at 0xcc.pw
Fri Oct 15 11:45:37 UTC 2021


On Friday, 15 October 2021 at 09:54:06 UTC, WebFreak001 wrote:
> On Thursday, 14 October 2021 at 22:56:07 UTC, hatf0 wrote:
>> Hi all,
>>
>> I've just managed to get the full DMD front-end to work in 
>> WebAssembly (with skoppe's druntime fork). This doesn't do 
>> code-gen or anything (but it potentially could?), and has some 
>> OS-specific functionality stubbed out. No clue about GC -- 
>> haven't run into that issue, haven't thought about it yet!
>>
>> You can find my work here if you're interested: 
>> https://github.com/hatf0/dmd-fe-wasm-wrapper
>>
>> This repo also serves as a semi-decent guide on how to get 
>> started building files that target WebAssembly (specifically 
>> WASI), if you're into that.
>
> neat! Given the low footprint of WASM apps maybe this could 
> maybe be used to have small isolated, cross-platform DMD tools 
> that run one-shot? Could for example run the WASM binaries from 
> the IDE and because it's WASM running in the own process, with 
> memory that we can free, it avoids low startup times, 
> especially on windows.

Definitely -- the sky is the limit at this point. Once I figure 
out the funkiness that's going on with the JS WASI runtimes, I've 
thought of doing things like having ddoc generation occurring at 
the edge (i.e. CloudFlare Workers). This would allow for 
dynamically generation of the documentation pages for Dub 
packages (or even, generating them on the client-side), and would 
mean less infrastructure complexity overall. Or hell, doing 
linting or other code analysis at package submission at the edge. 
There's *so* much that's possible since the full front-end is 
operable.

> Do we have some WASM runner in D?

We have https://code.dlang.org/packages/wasmer, which wraps the 
wasmer C runtime. This package /may/ need some tidying up (as 
wasmer is on v1.0.0 and this is still on a RC).



More information about the Digitalmars-d-announce mailing list