Add some rudimentary WebAssembly support #2766
Conversation
|
For testing, you can use the |
|
I did a quick experiment, and this works:
extern(C) double add(double a, double b) { return a + b; }
// seems to be the required entry point
extern(C) void _start() {}Compile:
<html>
<head>
<script>
const request = new XMLHttpRequest();
request.open('GET', 'wasm.wasm');
request.responseType = 'arraybuffer';
request.send();
console.log('request sent');
request.onload = () => {
console.log('response received');
const bytes = request.response;
const importObject = {};
WebAssembly.instantiate(bytes, importObject).then(result => {
console.log('instantiated');
const { exports } = result.instance;
// finally, call the add() function implemented in D:
const r = exports.add(42, -2.5);
console.log('r = ' + r);
});
};
</script>
</head>
<body>
Test page
</body>
</html>
|
|
Unfortunately, LLD needs another command-line-parsing workaround for |
kinke
force-pushed
the
wasm
branch
2 times, most recently
from
8a61805
to
e46cf56
Compare
driver/main.cpp
Outdated
| break; | ||
| case llvm::Triple::wasm64: | ||
| VersionCondition::addPredefinedGlobalIdent("WebAssembly64"); | ||
| VersionCondition::addPredefinedGlobalIdent("D_HardFloat"); // right? |
There was a problem hiding this comment.
Nice, I tried a similar test yesterday, because of the forum post, and must have hit the error below: the 1.11 beta said it couldn't recognize the CPU wasm32. I doubt they're exposing the FPU to wasm, they only mention IEEE-754 compatibility. My guess is the wasm itself is agnostic to how floating-point is implemented, so better to just not set a predefined version for it.
There was a problem hiding this comment.
This PR is the result of me playing around after the forum post. ;) Erroring out for an unknown architecture (just because we don't know what predefined version to emit) was the first showstopper, hence the warning instead to ease future experiments. [It's already a warning when the target OS is unknown.]
Wrt. D_HardFloat, I thought it'd fit when slightly adapting the semantics from the target hardware has a floating point unit (spec) to the target has floating-point instructions (https://github.com/WebAssembly/design/blob/master/Semantics.md#floating-point-operators); the term 'hardware' in the context of WebAssembly is pretty nebulous/useless.
There was a problem hiding this comment.
Well, hardware is what defines D_HardFloat, so I don't think it applies here. The point of the predefined version seems to be to allow you to write D code specialized to some FPU, which I don't think wasm allows. If you simply have floating-point instructions in your target, well, software implementations have those too.
My point is that I think both predefined versions are meaningless for wasm and shouldn't be defined. Those two predefined versions are hardly used in our stdlib anyway, doubt anyone outside is using them much.
There was a problem hiding this comment.
I'll just remove them after seeing that D_{Hard,Soft}Float aren't defined for RISC-V either.
Well, hardware is what defines D_HardFloat [...] If you simply have floating-point instructions in your target, well, software implementations have those too.
Right, so currently it actually isn't the hardware alone that defines D_{Hard,Soft}Float, but the target architecture and, for some archs, the -float-abi setting.
There was a problem hiding this comment.
I think that's only because some arches are assumed to always have an FPU, unlike ARM.
This gets some trivial code to compile to 32/64-bit WebAssembly via
ldc2 -mtriple=wasm{32,64}-unknown-unknown-wasm -c -betterC: