On Sunday, 5 November 2023 at 16:18:53 UTC, Sebastiaan Koppe wrote:
> On Sunday, 5 November 2023 at 01:28:25 UTC, Lingo Chen wrote:
>> https://v8.dev/blog/wasm-gc-porting
>>
>> wasmgc is shipping. any plan for porting?
>
> My understanding is that it requires emitting dedicated instructions for allocating such objects, as well as dedicated instructions for accessing them. Since LLVM doesn't support them, I am not sure what a possible path to support should look like, aside from writing a complete fresh backend.

https://llvm.org/devmtg/2022-11/slides/TechTalk3-ClangClang-WebAssembly.pdf

llvm ir seems to have support for the reftype(gc). so it a compiler problem?

On Monday, 6 November 2023 at 00:47:43 UTC, Lingo Chen wrote:
> On Sunday, 5 November 2023 at 16:18:53 UTC, Sebastiaan Koppe wrote:
>> On Sunday, 5 November 2023 at 01:28:25 UTC, Lingo Chen wrote:
>>> https://v8.dev/blog/wasm-gc-porting
>>>
>>> wasmgc is shipping. any plan for porting?
>>
>> My understanding is that it requires emitting dedicated instructions for allocating such objects, as well as dedicated instructions for accessing them. Since LLVM doesn't support them, I am not sure what a possible path to support should look like, aside from writing a complete fresh backend.
>
> https://llvm.org/devmtg/2022-11/slides/TechTalk3-ClangClang-WebAssembly.pdf
>
> llvm ir seems to have support for the reftype(gc). so it a compiler problem?

Unsure how it's progressed since but as can be seen on the last slide of that pdf, it's work in progress.

On Monday, 6 November 2023 at 11:05:45 UTC, Sebastiaan Koppe wrote:
> On Monday, 6 November 2023 at 00:47:43 UTC, Lingo Chen wrote:
>> On Sunday, 5 November 2023 at 16:18:53 UTC, Sebastiaan Koppe wrote:
>>> On Sunday, 5 November 2023 at 01:28:25 UTC, Lingo Chen wrote:
>>>> https://v8.dev/blog/wasm-gc-porting
>>>>
>>>> wasmgc is shipping. any plan for porting?
>>>
>>> My understanding is that it requires emitting dedicated instructions for allocating such objects, as well as dedicated instructions for accessing them. Since LLVM doesn't support them, I am not sure what a possible path to support should look like, aside from writing a complete fresh backend.
>>
>> https://llvm.org/devmtg/2022-11/slides/TechTalk3-ClangClang-WebAssembly.pdf
>>
>> llvm ir seems to have support for the reftype(gc). so it a compiler problem?
>
> Unsure how it's progressed since but as can be seen on the last slide of that pdf, it's work in progress.

As shown in my DConf presentation, yes, the GC can be a problem but it is a problem in a multitude of problems on the big picture. Having a complete libc working with D, for not needing to do a massive refactor in code is a really big problem. Asincify was used to fix that when using through EMScripten, while in my engine I took a completely different approach to fix that, but for common projects, it is not possible to have that if you want to port your project to WASM.

Even then, there's the communication as shown in the presentation, which currently I implement as a hack in my engine (which I discovered accidentally from the delegates generating an incrementing counter), having proper support to that would be totally essential.

So, having a working D Runtime and Phobos is a priority, while the GC problem is a thing the developer should not even care and is an eventual fix, a simple version upgrade that would make the projects simply better. Done is better than perfect, if we have no projects in webassembly, I don't believe anyone will get interested enough to implement it.

On Monday, 6 November 2023 at 11:05:45 UTC, Sebastiaan Koppe wrote:
>>
>> https://llvm.org/devmtg/2022-11/slides/TechTalk3-ClangClang-WebAssembly.pdf
>>
>> llvm ir seems to have support for the reftype(gc). so it a compiler problem?
>
> Unsure how it's progressed since but as can be seen on the last slide of that pdf, it's work in progress.

Kotlin abandoned llvm and implemented a new wasm backend. So waiting for llvm probably is not a good idea?

Is taking D's frontend + binaryen's backend a feasible solution? If wasmgc's architecture is a good fit for D. Can it be done quickly?

On Monday, 6 November 2023 at 23:44:11 UTC, Lingo Chen wrote:
> On Monday, 6 November 2023 at 11:05:45 UTC, Sebastiaan Koppe wrote:
>>>
>>> https://llvm.org/devmtg/2022-11/slides/TechTalk3-ClangClang-WebAssembly.pdf
>>>
>>> llvm ir seems to have support for the reftype(gc). so it a compiler problem?
>>
>> Unsure how it's progressed since but as can be seen on the last slide of that pdf, it's work in progress.
>
> Kotlin abandoned llvm and implemented a new wasm backend. So waiting for llvm probably is not a good idea?
>
> Is taking D's frontend + binaryen's backend a feasible solution? If wasmgc's architecture is a good fit for D. Can it be done quickly?

I have only looked approx 5 minutes at it, so its really hard to say. I expect it to be quite some effort.

There are some things we can do today that are smaller in scope and will help any future effort, such as reviving my druntime port. You are going to need that anyway, unless you go with the custom druntime or betterC route.

On Wednesday, 8 November 2023 at 09:06:31 UTC, Sebastiaan Koppe wrote:
> On Monday, 6 November 2023 at 23:44:11 UTC, Lingo Chen wrote:
>> On Monday, 6 November 2023 at 11:05:45 UTC, Sebastiaan Koppe wrote:
>>>>
>>>> https://llvm.org/devmtg/2022-11/slides/TechTalk3-ClangClang-WebAssembly.pdf
>>>>
>>>> llvm ir seems to have support for the reftype(gc). so it a compiler problem?
>>>
>>> Unsure how it's progressed since but as can be seen on the last slide of that pdf, it's work in progress.
>>
>> Kotlin abandoned llvm and implemented a new wasm backend. So waiting for llvm probably is not a good idea?
>>
>> Is taking D's frontend + binaryen's backend a feasible solution? If wasmgc's architecture is a good fit for D. Can it be done quickly?
>
> I have only looked approx 5 minutes at it, so its really hard to say. I expect it to be quite some effort.
>
> There are some things we can do today that are smaller in scope and will help any future effort, such as reviving my druntime port. You are going to need that anyway, unless you go with the custom druntime or betterC route.

Yes, would love you to revived the druntime port, but I think implemented the new wasmgc backend is necessary too.

https://www.pdl.cmu.edu/SDI/2022/slides/Wasm-Basis-of-Next-Gen%20Runtime-Systems.pdf

after reading through the slide, I think wasmgc is the only way forward for good Javascript interoperability, and that is critical for my use case(handling 3d data, which needs to be gc).

As Rikki stated, it just swapping llvm ir for wasmgc ir. Could be non-workable, but I think it worth a try.

No experience in writing compiler, but I can handle assembly/forth syntax just fine. Is anyone interested?

On Wednesday, 8 November 2023 at 13:29:46 UTC, Lingo Chen wrote:
> On Wednesday, 8 November 2023 at 09:06:31 UTC, Sebastiaan Koppe wrote:
>> On Monday, 6 November 2023 at 23:44:11 UTC, Lingo Chen wrote:
>>> On Monday, 6 November 2023 at 11:05:45 UTC, Sebastiaan Koppe wrote:
>>>>> [...]
>>>>
>>>> Unsure how it's progressed since but as can be seen on the last slide of that pdf, it's work in progress.
>>>
>>> Kotlin abandoned llvm and implemented a new wasm backend. So waiting for llvm probably is not a good idea?
>>>
>>> Is taking D's frontend + binaryen's backend a feasible solution? If wasmgc's architecture is a good fit for D. Can it be done quickly?
>>
>> I have only looked approx 5 minutes at it, so its really hard to say. I expect it to be quite some effort.
>>
>> There are some things we can do today that are smaller in scope and will help any future effort, such as reviving my druntime port. You are going to need that anyway, unless you go with the custom druntime or betterC route.
>
> Yes, would love you to revived the druntime port, but I think implemented the new wasmgc backend is necessary too.
>
> https://www.pdl.cmu.edu/SDI/2022/slides/Wasm-Basis-of-Next-Gen%20Runtime-Systems.pdf
>
> after reading through the slide, I think wasmgc is the only way forward for good Javascript interoperability, and that is critical for my use case(handling 3d data, which needs to be gc).
>
> As Rikki stated, it just swapping llvm ir for wasmgc ir. Could be non-workable, but I think it worth a try.
>
> No experience in writing compiler, but I can handle assembly/forth syntax just fine. Is anyone interested?



I think you didn't quite get, but reviving the runtime Sebastian done is way more critical than having the GC, and it is as he said, having a new backend is a far away dream, we should not jump steps. If the runtime is not revived, there is no point in having a GC at all, and it is impossible to use the GC without the runtime, but runtime without the GC, it is possible :)

On 09/11/2023 2:42 AM, Hipreme wrote:
> If the runtime is not revived, there is no point in having a GC at all, and it is impossible to use the GC without the runtime, but runtime without the GC, it is possible :)

That's not true.

You wouldn't need anything in druntime to make the wasm GC work. Everything would be done in the glue layer of the compiler and would be specific to that target.

The druntime bits for GC or TypeInfo wouldn't be used.

On Wednesday, 8 November 2023 at 13:52:34 UTC, Richard (Rikki) Andrew Cattermole wrote:
> On 09/11/2023 2:42 AM, Hipreme wrote:
>> If the runtime is not revived, there is no point in having a GC at all, and it is impossible to use the GC without the runtime, but runtime without the GC, it is possible :)
>
> That's not true.
>
> You wouldn't need anything in druntime to make the wasm GC work. Everything would be done in the glue layer of the compiler and would be specific to that target.
>
> The druntime bits for GC or TypeInfo wouldn't be used.

Yes, the wasmgc's main selling point is the sharing of GC and TypeInfo between Javascript and WASM.

Sharing of data between the JS/WASM are problematic. JS has no destructor, so it practically impossible to do manual memory/resource management in JS side; One has to do a lot of works to pass data around. c/c++/rust, non-gc system languages, are not a good fit for JS/WASM, but D if ported to wasmgc would be a great fit.

I think D is in a happy position here.

On Thursday, 9 November 2023 at 04:02:48 UTC, Lingo Chen wrote:
> Yes, the wasmgc's main selling point is the sharing of GC and TypeInfo between Javascript and WASM.

Not just javascript, but any WASM runtime.

> Sharing of data between the JS/WASM are problematic. JS has no destructor, so it practically impossible to do manual memory/resource management in JS side; One has to do a lot of works to pass data around.

With spasm I was auto-generating all glue code based off of WebIDL files. The post build step was annoying but it worked pretty well.

I even had a prototype that would do it for any typescript library.

Of course using WASM ref types is way more ergonomic.

One thing to note about WASMGC, it is MVP and missing a lot of things like support for interior pointers etc. There are workarounds but it's not so simple.