Alf-André Walla

I compiled with clang in freestanding mode and with a dash of a tiny libc + malloc implemented using syscalls. https://github.com/fwsGonzo/libriscv/blob/master/binaries/barebones/libc/heap.hpp https://github.com/fwsGonzo/libriscv/blob/master/emulator/src/native_libc.cpp Here, the system calls are only used to...

It looks like libc does not build at all, for any target. Perhaps it's best to just wait until it grows up and becomes buildable. I'm using clang-11 and cmake-3.17...

System calls are now part of the library itself, and many filesystem system calls are supported. There is also basic sockets support; enough for a TCP listener and basic read...

There is now just enough syscall emulation for a Golang hello world program

It wasn't as simple as it seemed. It might not be possible to do away with the way it's done. It will be possible to solve this once we move...

I think this will naturally go away if I decide to do simulation using computed goto. Closing for now.

There is no shared library support right now, although it would be possible to add support for simple shared libraries. I can whip up some code that lets you load...

Looking at https://godotengine.org/article/introducing-gd-extensions it seems to require you to compile shared libraries for your native system anyway. So [GDExtensionSummator](https://github.com/paddy-exe/GDExtensionSummator) would be compiled to amd64 (x86_64), or you can't load it...

I'm not sure what could cause that but there are some candidates. For example, in C++ there are often global objects with constructors and destructors, and guess what happens when...

It's likely because there's something wrong with the system call handler in `lib/libriscv/win32/system_calls.cpp`. None of the Linux system calls for Windows have been tested or even written properly. All they...