A bit more Emscripten

[Vladimir Panteleev]

On Tuesday, 8 May 2018 at 09:51:11 UTC, Mike Franklin wrote:
> I've been recently assigned the task of building a web-based 
> Ladder Logic editor/compiler 
> (https://en.wikipedia.org/wiki/Ladder_logic). This would not be 
> a short-lived application, however.

Hmm, sounds like this would be an interactive application that 
would need access to the HTML DOM. Currently, this isn't directly 
possible - when running in an asm.js VM, there is no D type to 
represent a JavaScript object. It is possible to call out to / 
eval JavaScript, though, so perhaps it could be possible using a 
shim, where a JavaScript array holds JavaScript/DOM objects, and 
D refers to them by index.

> I'm not sure if I would be much help with this, but know that 
> there is demand for it.  I think the difficult part would be 
> porting the D runtime to "browser" environment, and I'm not 
> sure what's involved with that, especially given all platform 
> dependencies that the runtime is currently bound to.

Here are some of the challenges with getting D to run on 
emscripten:

- Emscripten is neither Windows nor Posix, which causes most 
version(platform){...}else... blocks to fail. Emscripten does 
provide a libc (based on glibc, I think) which even abstracts 
some things like I/O and the filesystem, but the feature set is 
definitely less complete than the platforms we currently support, 
so there's lots of stubbing involved.

- As a result of this, some parts of Phobos simply have no way of 
working correctly. For example, a good part of std.math concerns 
itself with the floating-point environment and flags, but in our 
case these all come down to "whatever the browser gives you" - 
which is probably standardized, but not under your control. So, 
these definitions would need a version(dscripten){}else wrapper.

- In theory, garbage collection might be made to work, with 
extensive help from the compiler. The problem is that we are 
still using JavaScript's stack, which means we can't scan it for 
pointers. It could be worked around by getting the compiler to 
also place references to heap objects somewhere else, like a 
second stack. For the short term, a practical approach would be 
to use @nogc memory allocation / container libraries 
(std.allocator etc.) and minimize GC allocations (e.g. closures 
are still nice to have).

- Exceptions do not work - throwing simply aborts. C++ exceptions 
do work in emscripten, so I think this could be made to work if a 
compiler guru spends some time on it.

- Threads look like they could be made to work - emscripten seems 
to have some wrappers to create/control Web Workers through a 
libpthreads-like API.