self
self copied to clipboard
Cygwin Port
Here's the start of a Cygwin port. It's intended to be useful in of itself, but also as a stepping stone to a fully native port. This is a work in progress, but works well enough to run worldBuilder.self
(without UI) and tests runVMSuite
.
The _Spy
does not work at this time, because while most of Cygwin is compiled with settings that preserve the frame pointer, a few strategically chosen functions do not, including cygwait
, which is the function that implements blocking system calls. I'm wondering if it's possible to do its check for being inside the interpreter without relying on stack traversal.
The binary must currently be postprocessed with peflags -l0 vm/Self.exe
in order to run.
Maybe it will be better to use some portable virtual machine? JVM rocks, but the Erlang's BEAM can be a variant (with some problems with OOP support of cause 8)
As I understand, this issue not about porting to Cygwin (why not dozen lighter MinGW anyway?) but about making Self portable implementation. So, JVM and maybe Graal can be a good variant as it definitely oriented on object languages.
Another very important portable env is JavaScript & WASM: it may be the best variant as we need interactive Self instance which is good to run in a browser on any device.
With this latest push, snapshots load correctly.
Morphic now runs in X11!
The executable is now built with the correct flags, so manual modification with peflags
is no longer required.
Hi rockwalrus, This is very cool! As an initial thought, I'm a little wary of having LGPL code in the Self tree. At the moment everything here is under the Self licence. Is this necessary? It seems to be some imported functions from CYGWIN? Also I'll let people know that your working on this on the mailing list. It is very low volume -would you consider joining? Russell
I found the DLL that has _profil
in it and am linking to it instead now.
Any suggestions about how to get the _Spy
to work? As I said at the top, while most of Cygwin is compiled with settings that preserve the frame pointer, a few strategically chosen functions do not, including cygwait
, the function that implements blocking system calls.
I'm wondering if it's possible to do the monitor's check for being inside the interpreter without relying on stack traversal. If not, I'm not quite sure what to do. I can check if ebp
points within the region allocated for the current thread's stack, but there's no gaurentee that the compile won't decide to store a pointer to a stack allocated variable in ebp
for one of those functions. The old value of ebp
has to be on the stack somewhere, but there's no way to know what the offset will be. And this doesn't even start to cover the stack manipulation that CYGWIN has to do to implement signals in userspace, which may or may not end up being relevant.
I have a native port using Mingw underway, so perhaps this won't be necessary although it won't hurt obviously.
I have a native port using Mingw underway, so perhaps this won't be necessary although it won't hurt obviously.
How did you get that to work? Just install mingw?