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 :)
