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.
