www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.announce - Good News: Almost all druntime supported on arsd webassembly

reply Hipreme <msnmancini hotmail.com> writes:
Hello people. I have tried working again with adam's wasm minimal 
runtime, and yesterday I was able to make a great progress on it.

Currently, the only feature that I did not bother to implement 
support for was the try/catch/finally/throw friends. Pretty much 
only because I don't use in my engine. I would like to ask you 
guys some feedback on its current usage, I have written a file 
with only tests to the wasm runtime:

```d
// ldc2 -i=. --d-version=CarelessAlocation -i=std 
-Iarsd-webassembly/ -L-allow-undefined -ofserver/omg.wasm 
-mtriple=wasm32-unknown-unknown-wasm 
arsd-webassembly/core/arsd/aa 
arsd-webassembly/core/arsd/objectutils 
arsd-webassembly/core/internal/utf 
arsd-webassembly/core/arsd/utf_decoding hello 
arsd-webassembly/object.d

import arsd.webassembly;
import std.stdio;

class A {
	int _b = 200;
	int a() { return 123; }
}

interface C {
	void test();
}
interface D {
	void check();
}

class B : A, C
{
	int val;
	override int a() { return 455 + val; }

	void test()
	{
		rawlog(a());
		int[] a;
		a~= 1;
	}
}

void rawlog(Args...)(Args a, string file = __FILE__, size_t line 
= __LINE__)
{
	writeln(a, " at "~ file~ ":", line);
}


struct Tester
{
	int b = 50;
	string a = "hello";
}
void main()
{
	float[] f = new float[4];
	assert(f[0] is float.init);
	f~= 5.5; //Append
	f~= [3, 4];
	int[] inlineConcatTest = [1, 2] ~ [3, 4];

	auto dg = delegate()
	{
		writeln(inlineConcatTest[0], f[1]);
	};
	dg();
	B b = new B;
	b.val = 5;
	A a = b;
	a.a();
	C c = b;
	c.test();
	assert(cast(D)c is null);
	Tester[] t = new Tester[10];
	assert(t[0] == Tester.init);
	assert(t.length == 10);

	switch("hello")
	{
		case "test":
			writeln("broken");
			break;
		case "hello":
			writeln("Working switch string");
			break;
		default: writeln("What happenned here?");
	}
	string strTest = "test"[0..$];
	assert(strTest == "test");

	
	Tester* structObj = new Tester(50_000, "Inline Allocation");
	writeln(structObj is null, structObj.a, structObj.b);

	int[string] hello = ["hello": 500];
	assert(("hello" in hello) !is null, "No key hello yet...");
	assert(hello["hello"] == 500, "Not 500");
	hello["hello"] = 1200;
	assert(hello["hello"] == 1200, "Reassign didn't work");
	hello["h2o"] = 250;
	assert(hello["h2o"] == 250, "New member");


	int[] appendTest;
	appendTest~= 50;
	appendTest~= 500;
	appendTest~= 5000;
	foreach(v; appendTest)
		writeln(v);
	string strConcatTest;
	strConcatTest~= "Hello";
	strConcatTest~= "World";
	writeln(strConcatTest);
	int[] intConcatTest = cast(int[2])[1, 2];
	intConcatTest~= 50;
	string decInput = "a";
	decInput~= "こんいちは";
	foreach(dchar ch; "こんいちは")
	{
		decInput~= ch;
		writeln(ch);
	}
	writeln(decInput);
	int[] arrCastTest = [int.max];

	foreach(v; cast(ubyte[])arrCastTest)
		writeln(v);

}
```

All those tests are currently passing. That means we almost got 
all the common features from the D Runtime into Arsd custom 
runtime. Meaning that the only thing that would be missing right 
now being the WASI libc. But my engine is not going to use it 
entirely, only a subset of it. So, I would like to say that 
whoever wants to play with it now is able to do it so.


That being said, I would carefully advice that while I bring 
those implementations, I didn't care about memory leaks, so, it 
is a runtime without GC: careless allocations. But! It is 
possible to port some programs specially if you're already doing 
house clearing yourself. As my engine does not leak memory in 
loop (as that would make it trigger the GC and thus make it 
slow), it is totally possible to use it.

"But why didn't you continued Skoppe's WASM work?", I literally 
am not able to build LDC runtime no matter how hard I tried. 
Doing that work on a minimal runtime was a lot easier.

If you do find any use in the work I've done, please do test it 
as I'll benefit from both you guys test. If you find any 
performance improvement on it, it'll be gladly be accepted.

I do not intend to replace the druntime with that. I've done the 
minimal subset of features that makes my engine work for the web. 
A real druntime is still expected and awaited by me.

The link to the PR to be tested can be found there: 
https://github.com/adamdruppe/webassembly/pull/9
Jan 06
next sibling parent reply "H. S. Teoh" <hsteoh qfbox.info> writes:
On Fri, Jan 06, 2023 at 12:52:43PM +0000, Hipreme via Digitalmars-d-announce
wrote:
 Hello people. I have tried working again with adam's wasm minimal
 runtime, and yesterday I was able to make a great progress on it.
[...]
 All those tests are currently passing. That means we almost got all
 the common features from the D Runtime into Arsd custom runtime.
 Meaning that the only thing that would be missing right now being the
 WASI libc. But my engine is not going to use it entirely, only a
 subset of it. So, I would like to say that whoever wants to play with
 it now is able to do it so.
 
 
 That being said, I would carefully advice that while I bring those
 implementations, I didn't care about memory leaks, so, it is a runtime
 without GC: careless allocations. But! It is possible to port some
 programs specially if you're already doing house clearing yourself. As
 my engine does not leak memory in loop (as that would make it trigger
 the GC and thus make it slow), it is totally possible to use it.
[...] This is awesome stuff, thanks for pushing ahead with it!! Keep this up, and I might actually decide to use your game engine for my projects. ;-) The big question I have right now is, what's the status of interfacing with web APIs such as WebGL? How much JS glue is needed for that to work? My dream is for all of the JS boilerplate to be automated away, so that I don't have to write a single line of JS for my D project to work in WASM. T -- Those who don't understand Unix are condemned to reinvent it, poorly.
Jan 06
parent Adam D Ruppe <destructionator gmail.com> writes:
On Friday, 6 January 2023 at 22:13:15 UTC, H. S. Teoh wrote:
 The big question I have right now is, what's the status of 
 interfacing with web APIs such as WebGL?
This part is really easy, you can call it from D with the opDispatch or pass it through as eval strings.
Jan 06
prev sibling next sibling parent reply Ferhat =?UTF-8?B?S3VydHVsbXXFnw==?= <aferust gmail.com> writes:
On Friday, 6 January 2023 at 12:52:43 UTC, Hipreme wrote:
 Hello people. I have tried working again with adam's wasm 
 minimal runtime, and yesterday I was able to make a great 
 progress on it.

 [...]
This sounds great. Thank you for your efforts. I will play around with it someday. I have not touched my pet game a while [1]. I used emscripten for sdl, and skoppe's druntime fork. One question. Does GC work with Adam's druntime for wasm? If yes, how? IMHO, D's GC need a second thread, which is a problem with wasm. 1: https://github.com/aferust/drawee
Jan 06
parent reply Adam D Ruppe <destructionator gmail.com> writes:
On Friday, 6 January 2023 at 22:14:23 UTC, Ferhat Kurtulmuş wrote:
 One question. Does GC work with Adam's druntime for wasm?
I haven't actually written one yet, so it leaks if you don't pay attention yourself. But I have a plan that should work: you do the setTimeout(collect, 0) so it runs when the event loop is idle. Then the wasm stack is empty so you can scan pure memory.
 IMHO, D's GC need a second thread
This isn't true, it never needs a second thread, even on normal desktop. The problem with GC on wasm is the webasm stack is opaque. You can have the compiler output a shadow stack or my plan of scanning when it is empty. Either should work but I haven't had time to implement anything.
Jan 06
parent Ferhat =?UTF-8?B?S3VydHVsbXXFnw==?= <aferust gmail.com> writes:
On Friday, 6 January 2023 at 22:39:36 UTC, Adam D Ruppe wrote:
 On Friday, 6 January 2023 at 22:14:23 UTC, Ferhat Kurtulmuş 
 wrote:
 One question. Does GC work with Adam's druntime for wasm?
I haven't actually written one yet, so it leaks if you don't pay attention yourself. But I have a plan that should work: you do the setTimeout(collect, 0) so it runs when the event loop is idle. Then the wasm stack is empty so you can scan pure memory.
 IMHO, D's GC need a second thread
This isn't true, it never needs a second thread, even on normal desktop. The problem with GC on wasm is the webasm stack is opaque. You can have the compiler output a shadow stack or my plan of scanning when it is empty. Either should work but I haven't had time to implement anything.
thank you for the clarification, Adam.
Jan 09
prev sibling parent Guillaume Piolat <first.last spam.org> writes:
On Friday, 6 January 2023 at 12:52:43 UTC, Hipreme wrote:
 Hello people. I have tried working again with adam's wasm 
 minimal runtime, and yesterday I was able to make a great 
 progress on it.
Awesome! To think that custom druntime can get you out of platform situations is great risk reduction.
Jan 07