This is my proposal for porting D runtime to WebAssembly. I would like to ask you to review it. You can find it here: https://gist.github.com/skoppe/7617ceba6afd67b2e20c6be4f922725d

On Saturday, 23 November 2019 at 09:51:13 UTC, Sebastiaan Koppe wrote:
> This is my proposal for porting D runtime to WebAssembly. I would like to ask you to review it. You can find it here: https://gist.github.com/skoppe/7617ceba6afd67b2e20c6be4f922725d

While I can't say anything on the details, the document looks well prepared. Thanks a lot for your work, it is very good starting point.

Kind regards
Andre

On Saturday, 23 November 2019 at 09:51:13 UTC, Sebastiaan Koppe wrote:
> This is my proposal for porting D runtime to WebAssembly. I would like to ask you to review it. You can find it here: https://gist.github.com/skoppe/7617ceba6afd67b2e20c6be4f922725d

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.
(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 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).

Can you elaborate on how you envision CI testing?
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)

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

Great initiative!
  Johan

On Saturday, 23 November 2019 at 09:51:13 UTC, Sebastiaan Koppe wrote:
> This is my proposal for porting D runtime to WebAssembly. I would like to ask you to review it. You can find it here: https://gist.github.com/skoppe/7617ceba6afd67b2e20c6be4f922725d

Yes, if I read this right the plan is to keep the runtime small. That is good, small footprint is important.

Also, if applicable, structure the object file in way that compress well (gzip). E.g. the layout of compiler emitted data structures and constants on the heap.

On Saturday, 23 November 2019 at 09:51:13 UTC, Sebastiaan Koppe wrote:
> This is my proposal for porting D runtime to WebAssembly. I would like to ask you to review it. You can find it here: https://gist.github.com/skoppe/7617ceba6afd67b2e20c6be4f922725d

I was wondering whats your position on Fibers?
Can they be implemented in current WebAssembly?

If so I'd guess they would be a nice match for async related functionality javascript is known for.

Best regards,
Alexandru.

On Saturday, 23 November 2019 at 10:29:24 UTC, Johan Engelen wrote:
> 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.

On Saturday, 23 November 2019 at 12:40:20 UTC, Ola Fosheim Gr wrote:
> On Saturday, 23 November 2019 at 09:51:13 UTC, Sebastiaan Koppe wrote:
>> This is my proposal for porting D runtime to WebAssembly. I would like to ask you to review it. You can find it here: https://gist.github.com/skoppe/7617ceba6afd67b2e20c6be4f922725d
>
> Yes, if I read this right the plan is to keep the runtime small. That is good, small footprint is important.

Small footprint is super important, especially when targeting the browser.

The first stage is getting something to work though, but I will definitely chisel bytes off afterwards.

> Also, if applicable, structure the object file in way that compress well (gzip). E.g. the layout of compiler emitted data structures and constants on the heap.

I don't know how much control we have (or want) over this. In the end LLVM and wasm-lld do that and we just piggyback that.

On Saturday, 23 November 2019 at 15:23:41 UTC, Alexandru Ermicioi wrote:
> On Saturday, 23 November 2019 at 09:51:13 UTC, Sebastiaan Koppe wrote:
>> This is my proposal for porting D runtime to WebAssembly. I would like to ask you to review it. You can find it here: https://gist.github.com/skoppe/7617ceba6afd67b2e20c6be4f922725d
>
> I was wondering whats your position on Fibers?

I am not going to support them in this initial port. And to be honest I rather see us moving towards stackless coroutines.

> Can they be implemented in current WebAssembly?

I haven't looked into it. I suppose they could be, since go has their goroutines supported in wasm as well.

But I don't think it is easy. WebAssembly uses the Harvard architecture, which means code and data is separate and code isn't addressable. That is why wasm uses a function table and indexes instead of function pointer addresses. So things like moving the instruction pointer are out.

> If so I'd guess they would be a nice match for async related functionality javascript is known for.

You can still use the JavaScript eventloop, either browser or node.

On 11/23/19 3:48 PM, Sebastiaan Koppe wrote:
> On Saturday, 23 November 2019 at 15:23:41 UTC, Alexandru Ermicioi wrote:
>>
>> I was wondering whats your position on Fibers?
> 
> I am not going to support them in this initial port. And to be honest I rather see us moving towards stackless coroutines.

I really hope you're right. I've been pushing for those for years, but never got the impression anyone else cared. The fact that C# has had them for eons and D still seems to have no interest in coroutines that *don't* involve the overhead of fibers bothers me to no end.

I did started working on a couple DIPs for them, though. Interestingly, I just found out today about C++'s proposed coroutines and was shocked by how similar they are to what I was designing; even right down to details like how the existence of a yield instruction is what triggers the compiler to treat the function as a coroutine, and the requirement that a coroutine's return type be a special type that includes the state information.

Still, a few differences, though. For example, unlike the C++ proposal, I'm hoping to avoid the need for additional keywords and heap allocation. And I also started a secondary DIP that builds on the coroutine foundation to make a much cleaner user-experience using the coroutines to generate ranges (what I would expect to be the most common use-case).

On Saturday, 23 November 2019 at 23:21:49 UTC, Nick Sabalausky (Abscissa) wrote:
> On 11/23/19 3:48 PM, Sebastiaan Koppe wrote:
> years, but never got the impression anyone else cared. The fact that C# has had them for eons and D still seems to have no interest in coroutines that *don't* involve the overhead of fibers bothers me to no end.

Fun fact: Simula had stackless coroutines in the 1960s... :-)

Well, I guess I have to add that they were stackless because the language was implemented with closure-like-objects, so there was no stack, only activation records on the heap. Actually, I believe the MIPS architecture had this as their default too (or maybe it was another CPU, anyway, it has been a thing.)