WebAssembly progress

Do not bet on this, because it is ported. The BeIDE sources also leaked and some (russian folks) patched it.

1 Like

BeIDE binary runs as-is without porting with minor issues.

1 Like

Thats true too.

The BeIDE sources mentions 3 copyright holder:

  • Metrowerk
  • Be
  • a guy

I contacted NXP (they own the Metrowerks IP) and asked for relicensing their stuff, also contacted the guy, but i got no answer from them.
End of story.

1 Like

Interesting. BeIDE is a lot nicer to use than the alternatives on Haiku. I thought there were issues with the way the dev tools are now packaged though? BeIDE expected them in specific locations and the gcc plugin was problematic. Does it work on 64bit also?

1 Like

If you recompile it, then sure.

Maybe PowerPC compiler can be opened?

I spoke to someone at Metrowerks a long time ago (I forget his name, but he was the developer advocate and he was quite infamous int he Metrowerks community.) He told me he would look in to it. I never heard much back.

AFAIK, Be Inc had the IDE source, but the compiler was binary only and came from Metrowerks. The same compiler was used to compile PEF on all platforms (Classic MacOS, MacOS X, Windows and BeOS), so there are later versions of it kicking around. I guess any of the versions being opensourced would be handy.

I tried to find out who owns the Metrowerks IP, but it is unclear.

Afair MW was bought by Freescale, and its compiler business was bought by NXP. But i can be wrong.

They have absolutely no email address on their webpage (because fck do not disturb us mortal human), so i had to make extra miles.

You can try to contact them, maybe you will have more luck.

Re:Double Mangle condition

Looking at the source, wasm2c has a mechanism to prevent the double mangle so I may be able to simplify the test script.

UPDATE:

The source code to Haiku is full of preprocessor magic. Of course this defines the architecture long before the bytecode can be generated so every instance of

#ifdef __IM_A_PREPROCESSOR_FLAG
  do this;
#endif

needs to be replaced with

if (__IM_A_BOOLEAN_CONST) {
  do this;
}

so that

#define __IM_A_PREPROCESSOR_FLAG 1

can be repaced with

extern const bool __IM_A_BOOLEAN_CONST;

thus allowing the value of __IM_A_BOOLEAN_CONST to be linked in on the destination machine and the if statement to be constant folded by the link-time optimization pass.

Itā€™ll be monotonous work but more importantly, will touch almost every part of the source code of the operating system. Expensive as a time sink even though the work is easy. Iā€™m guessing that this may not make it to Beta 4, to say the least. Even worse, the GCC2 ABI requirement wonā€™t be met without an alternative compiler that supports link-time optimization.

I will welcome any critique of the situation but the amount of work that will be needed to merge all the packages into one bytecode may have to wait until the ā€œglass elevatorā€ arrives on the first floor. (Meaning that it may have to wait until after release 1.)

Edit: If everybody was willing to pitch in and replace all the preprocessor macros in the config directory with constants, we collectively could make it beta 4!

6 Likes

CodeWarrior (the MacOS equivalent to BeIDE) is now owned by NXP but the current versions seem to be based on the Eclipse IDE and the GCC compiler: CodeWarriorĀ® Embedded Software Development Tools | NXP Semiconductors

I donā€™t know if they still have backup of the older versionsā€¦

We can send them the x86 one.

On to plan B. Iā€™m going to try to update the ApplicationKit headers so they donā€™t need to include the config.h macros as preprocessor definitions. Once I see what breaks Iā€™ll report back.

Update

The extent of what I can accomplish for architecture neutrality using static compilation is limited by address bit width and endianness. This means 68k and Sparc32 can share a bytecode, as can PPC32 and ARMEB, but not x86 because it is little-endian. Little-endian 32-bit processors like ARM and x86 will be able to share a different bytecode. Futhermore, AMD64 and RISC-V64 will be able to share a bytecode because they are both little-endian and 64-bit. Finally, the fourth bytecode will be big-endian 64-bit.

Running a smaller address width or endian-swapped architecture (or both) will only be possible using a JIT. The speed penalty can be minimized by using a fast JIT like Cranelift but it will still have a speed penalty due to the compilations being concurrent or at load-time using AOT compilation.

Future Opportunities

I intend to fork bytecodes from the WebAssembly standard to support features that it presently does not support. 64-bit WebAssembly is going to be supported soon by the W3C so no need to fork for that. Two other features not supported or planned to be are big-endian platform support and macro injection.

Big-endian support will only require adding multi-byte loads and stores. I would not recommend using the same bytecode values for a big-endian load and store in case bi-endianness is supported as PPC and AArch64 both do endian swapping with a fair degree of transparency.

The final nail in fixed architecture is code injection. Normally associated with JIT compilation, code injection allows library code to contain macros in such a way that code from a performance limited libraries such as graphics drivers can actually put driver code in the executable of the application. This removes calling overhead from what might be implemented as a subroutine on one architecture, but a few opcodes on another. While often performed in JIT and AOT compilation strategies, it can also be implemented in static code by invoking a dependency check at startup.

More to comeā€¦

1 Like

More Updating

Iā€™ve gotten Clang to compile my graphical ā€œHello worldā€ class executable from Clang after having modelled it after the beginning example from the beginnersā€™ tutorial. The command lines to build are much different. The significance of this is that GCC doesnā€™t have a WebAssembly backend to generate bytecode with.

The GCC build line is as follows:

g++ App.cpp -Os -lbe

The Clang 12 build line is this:

clang++ App.cpp -I/boot/system/develop/sources/haiku/headers/build/gcc-2.95.3 -fPIC -Os -lbe

The extra included directory contains the headers to the LibStdC++ runtimes. Apparently activating Position Independent Code is not optional either but must be specified. The resultant code is a couple hundred bytes smaller with Clang 12 than with GCC8, but thatā€™s not a fair comparison considering that Clang 12 is on par with GCC 10 or 11 as far as generations go.

Hereā€™s the C++ source listing of the program:

#include "App.h"

#include <StringView.h>
#include <Window.h>

App::App(void)
	:	BApplication("application/x-vnd.dw-TestApp")
{
	BRect frame(100,100,500,400);
	BWindow *myWindow = new BWindow(frame, "My First App", B_TITLED_WINDOW,
		B_QUIT_ON_WINDOW_CLOSE);
	frame.Set(10,10,11,11);
	BStringView *label = new BStringView(frame, "myLabel", "Haiku Rocks!");
	label->ResizeToPreferred();
	myWindow->AddChild(label);
	myWindow->Show();
}


int
main(void)
{
	App *app = new App();
	app->Run();
	delete app;
	return 0;
}

The App.h file is this:

#define APP_H

#include <Application.h>

class App : public BApplication
{
public:
	App(void);
};

#endif

Now to get Clang to generate bytecode like Iā€™ve already done on Linux.

Stay tunedā€¦

2 Likes

But then

Now which ABI is targeted here? GCC2 or GCC4? If GCC4 then why the GCC2 include folder? If GCC2 then why ā€œcouple hundred bytes smaller with Clang 12 than with GCC8ā€ ?

And if GCC2, let me ask: wouldnā€™t it easier to support only one ABI? One donā€™t really need to compile the whole os into webassembly, and most of the user-programs can be built with GCC4 ABI, then why to mess with the GCC2 ABI at all?

(Maybe I overlooked something here.)

And that include path doesnā€™t look to be shipped in default to me.

Tell me where the ABI v4 headers are to direct toward. Iā€™ll try it. When I did a search for ā€œnew.hā€ that was the only one that showed up.

GCC2 is not compatible with Clang. GCC 4+ headers should be used.

1 Like

-I/boot/system/develop/tools/x86/lib/gcc/i586-pc-haiku/8.3.0/include/c++ -I/boot/system/develop/tools/x86/lib/gcc/i586-pc-haiku/8.3.0/include/c++/i586-pc-haiku

/x86 need to be removed for 64 bit system.

3 Likes

I agree. Where is the ABI v4 header for new.h? This was just the first attempt to make a graphical application work on Clang 12.

Edit: Thanks for the correct path.