I am just not really clear what you are doing any more. It sounds like you compile C to C and compile the second set to a binary? That can’t be it, but where does web assembly come in? How does the toolchain go?
C---->WASI
WASI---->C
C---->x64
I am guessing this is it but you’ve never really stated it anywhere that I’ve seen.
In Python’s case, the version 3.11 of the Python language being compiled here is newer than Haiku’s current version: 3.9. Yet the wasm version might have compiled more promptly because no patches were needed.
In the case of Clang8, C++14 was used for the development version but WebAssembly compiled it down to vanilla C from 1990 yet still needed no patching.
Finally, using a universal function dispatcher, the linkage order can be easily disregarded, making building in parallel a breeze. It’s all runtime ops and optimization from here.
This is pretty interesting on it’s own: It sounds as though it could be used to port new code to systems with old compilers.
Small side note:
Most (if not all) of the patches needed for Python (here’s the one for 3.9 for reference) has to do with making Python work correctly under Haiku (including modules, extensions, installation paths, etc. etc.) more than with making sure it can be built.
We’ve had 3.11 running since mid October but that’s not merged because it needs fine tuning, and some fixes in the patchset it is based on (the 3.10 that has some bugs in it compared to 3.9 regarding module installation paths, for example).
/me walks back into the shadows
Yes! Perhaps this is just what the doctor ordered for GCC2 on Haiku x86! Unlike Wasm2C in the WebAssembly Binary Toolkit, aka WABT (which I’m also working on), which builds a massive single .c file, W2C2 supports parallel builds very efficiently by putting only a certain number of functions per .c file. There is one .c file that acts as a dispatcher that ties all the others together so the linkage order doesn’t hurt anything. I think it’s a good thing for all involved.
Why would you use gcc2 unless you want to target beos or have code you can’t update?
Because you said gcc2 on Haiku 
I really don’t see why you would use it, all arches have gcc11 or llvm available 
OK, BeOS then.
If you were to build a gcc2h x86 haiku (if such a thing is still possible, perhaps not) it would be useful for running new drivers and plugins on such an old system. The only advantage of such a system is binary driver compatibility with beos, though.
After having worked and researched on the idea of having all closed-source software in bytecode since 1993, my last year of high-school, it appears that bytecodes don’t generate code that’s “native” enough on most platforms. In the case of having built Python and Clang examples on W2C2, I can certainly say that WebAssembly won’t be a fit form of package for a package manager to use any moreso than a source package. I see that it will require a complete compilation stage to native executable format in .HPKG format before it will be useful. The execution speed is acceptable once the compilation is complete though.
For now, I’m going to scale back the scope of my WebAssembly studies to the point that it will be one of many tools used by HaikuPorts to create packages. As a command-line utility, it works as well as any other compilation strategy but installs from bytecode in minutes rather than seconds when compiling on all threads of all cores at once.
My initial idea of tacking on LibGCCJIT on every parallel thread in a WebAssembly compiler will not be likely to speed up the code generation process more than a few seconds per build. W2C2 is extensivly multithreaded already. The generation of C code is very effectively optimal but the optimization of the code generation is the bottleneck. The I/O would have been diminished by cutting the C code generation and parsing in between but I think that micro-optimization kills most of the speed advantages of bytecode. I’ll have to do some speed tests.
I know that doing a parallel build of Clang 14 took a half-hour on Linux. Doing a bytecode compile of Clang 8 takes quite a while also, though less than a half-hour. I think I’d better do some profiling. I’ll time the build process from source and compare to bytecode building to see what the gain actually is.
Please explain how you’re going to bind the new code that went through WASM transformations with the native C++ code, compiled with gcc2 and using an ABI that no modern compiler supports, no matter how much abstraction layers or transformations you put in between.
So, yes, this can be useful to run new code on old unsupported operating systems, maybe, but you still will have trouble using the native APIs unless… you somehow write a binding for them. And if you did that, you might as well port a modern C compiler in much simpler ways (there used to be gcc3 and 4 for BeOS, it just couldn’t be used with the native BeAPI due to the ABI problem).
Me? I don’t intend to and never suggested I would. It’s more theoretical conjecture and interesting discussion. I’ll try not to casually discuss ideas on the discussion forums without fully thinking through a complete engineering solution in future, apologies.
Good point there, I don’t have a solution for that off hand, I agree.
That’s exactly what Haiku is missing. Theoretical conjectures.
Assuming the ABI allows for name mangling, yes. BeOS did but the name mangling scheme didn’t work on the newer name mangler of GCC3+.
I do think that making a wrapper for BeAPI would be useful for filling in the many gaps of the WASI standard. Presently WASI is just getting around to adding threads and setjmp.h support for exception handling. I’d probably have to ditch WASI in favor of a proprietary format for BeAPI specifics. That means inventing yet another name mangler I think. 
Or at least a name translation layer. 
I think what the forum is missing is encouragement for new ideas and open discussion. It has plenty of patronising, though.
Hey I didn’t say it is not possible, just pointing out there is one problem with the ABI compatibility, which is not solved by this approach in its current state. My goal is not to discourae this, but to advance the discussion into how this may be solved.
This sets expectations about what’s currently possible, what the possible limitations currently are, and allows to go further into the plans for this.
Understood, and that’s great. To be clear I am only trying to be helpful and encourage new ideas too. I don’t 100% follow the webassembly development but I think it’s very interesting and technically impressive, and there may be useful applications for it even if those aren’t entirely clear yet.
If I were to write a Haiku API for C outputs whose names are in C++ ABI name mangled form, I think I could add a name translation layer to the GCC2 BeAPI to allow greater binary compatibility with BeOS. Does Haiku 32-bit already have such a solution as this or does it just use a secondary ELF loader?
