W2C2 is a biendian WebAssembly to C89 transpiler. If the WASI standard bindings were generated for MorphOS, it would allow up-to-date versions of Python 3.11 and other WebAssembly bytecodes using the WASI standard outside the browser to work.

The devil is in the details and the fact that the runtimes haven't been ported to MorphOS yet. An early version might need IXEmul.library, for example. It already runs on Haiku so the POSIX requirements aren't too stiff for now. Other non-POSIX operating systems like MacOS 9 are already supported.

I'm willing to pitch in if somebody else will work with me on it. I have a history of starting things and not finishing them so I need an accountability partner at least. If I try it myself, I will be unlikely to make it to completion.

w2c2.png

I couldn't get python to build, though... Will give it another go tomorrow.

Update: python builds but crashes :)

[ Edited by jacadcaps 23.03.2024 - 03:35 ]

Well, this thing was a colossal waste of time :) Even if you do get python to work, it gets confused by Amiga-style paths (even with ixemul). So now you're looking at making MorphOS specific changes in cpython, compiling that to WASI, translating that via w2c2 to C and compiling that... That's just ridiculous.

Well, this thing was a colossal waste of time :) Even if you do get python to work, it gets confused by Amiga-style paths (even with ixemul). So now you're looking at making MorphOS specific changes in cpython, compiling that to WASI, translating that via w2c2 to C and compiling that... That's just ridiculous.

Quote:
Thanks for trying. I suspect the runtimes are the culprit though, WASI standards are supposed to be fully platform independent. Maybe some future version will work better.

Edit:
If I recall correctly, Python has an external module called "system" which contains all system-specific code. If VM-Ware (or whomever supplied the .WASM file for Python) inlined all the calls to a POSIX implementation of the "system" class, the resultant binary will choke on non-POSIX paths as indicated.


[ Edited by Samurai_Crow 25.03.2024 - 10:16 ]

Quote:

Thank you for opening a GitHub issue for the miscompilation (https://github.com/turbolent/w2c2/issues/96).

It great to see that coremark builds and runs

Are you saying you tried to build Python with that fix, you managed to compile the WASI library, and when running the Python binary, it crashes? Would you be able to share more details? Are you able to attach a debugger and get a stack trace?

My guess is that the WASI implementation might need some tweaks, IDK how POSIX-compliant MorphOS is.
I bet that Python can't find the standard library (https://github.com/turbolent/w2c2/tree/main/examples/python/lib, set via environment variable PYTHONHOME), because MorphOS has a different notion for paths (i.e. non-POSIX paths), and needs path translation functions just like already exist for Windows and Classic MacOS (see e.g. https://github.com/turbolent/w2c2/blob/main/wasi/mac.c).

I do have various PowerPC systems, but no license for MorphOS. I might try to install it and see myself

Quote:

Like I mentioned in my previous post, no changes to Python itself should be needed. It should be possible to implement the translation between Amiga-style paths and POSIX paths in the WASI library, just like it already has support for Classic MacOS paths (: separator).

Once the WASI library has support for MorphOS, that would open up porting all sorts of applications, e.g. Python, Ruby, Clang/LLVM, without any further changes/effort.

This is exactly what I created w2c2 for

Quote:

Even on unregistered MorphOS, you can run for a half-hour at full-speed before the license times out and you need to reboot to reset the timer. I consider the registration cost to be worth it to any present or former Amigan to get the full MorphOS experience.

Thanks for stopping by to see what was going on.

@turbolent

Sorry for only noticing your post now.

As far as I can tell, python crashes early in its initialization (python__start being the last named call). It's really odd cause I did manage to get it to the python prompt when stepping via gdb. Without gdb it appears to call 3 functions recursively until it runs out of stack and crashes (tried 64MB stack afair).

Btw, is there a gcc version you'd recommend? We've got anything from 2.95.3 to 12 :)

[ Edited by jacadcaps 04.04.2024 - 03:58 ]