68k binaries on next gen platforms.

[Steffest]

Hi,

I dabbled a bit in System Friendly coding in C for Classic OS and (after lots of banging on things) I managed to cobble together a basic program that has some potential.
Some buttons, inputs, user interaction, graphics, even doing http requests, download images and display them on screen.
(Hey, call it what you will, but that's an internet browser right there, no? :-) )

A bit to my surprise, the 68k binary also works on next gen systems like OS4, morphos and Aros.
I don't know anything about these NG systems but I assume they do some on-the-fly CPU emulation and map the system calls to their native API?

I must say, the thought of maintaining 1 single binary that works on all those systems is appealing, but before I put a considerable amount of time and effort into this I have a question:
Is it even a good approach to aim for this "one binary fits all" or would it be far far better to compile a dedicated version for all these platforms?
Are there any limitations running e.g. 68k binaries on PPC or x86 architecture, memory-wise or feature-wise?

Thanks,
Steffest

[Samurai_Crow]

First of all, running 68k binaries on AROS x86 requires an emulator called JanusUAE because the binary compatibility is still being written and is being written in AArch64EB Assembly, NOT x86. If you don't already know, AArch64EB is big-endian mode ARM 64-bit like the Raspberry Pi 4.

Beyond that, Amiga OS 4 has Petunia and MorphOS has Trance. They offer binary compatibility at a cost of a small amount of processor overhead to run the JIT compilers and don't support chipset emulation. MorphOS uses CyberGraphX 4 and OS4 uses P96 so using CyberGraphX 3 is compatible with both. Also, the Reaction GUI that has been available since AmigaOS 3.5 is not available on MorphOS nor AROS due to exclusive licensing (though installing the older ClassAct demo from the Aminet should be compatible). MUI 3.8 works on all Amiga-likes.

When MorphOS reaches version 4.0 it will run on a fixed x64 platform and will JIT both 68k and PPC on that platform. That's 64-bit x86.

All things considered your milage may vary. 68k compatibility is available but not consistent between next-gen platforms. Multiple binaries are definitely the preferred option because there's enough incompatibility between the different OS's to justify it and PPC cross compilers are generally the less painful option.

[Steffest]

Thanks for the detailed explanation.

For the moment I'm staying clear of Reaction, ClassAct and MUI.

I also must say I'm totally new to C - my usual dev-world is javascript - so I still have to find/create/mold my entire toolchain.
I'm just trying out stuff and building small UI components in a way that feel natural to me and that I can wrap my head around.

The main target is OS3, but it's a nice exercise to find the largest common subset in system calls that works on all those platforms.
If I'm starting from scratch anyway, I might as well build stuff that works on multiple platforms.
(And you're right, in case of Aros it was one of the x68 variants I tested)

[jPV]

I think it's a fine option to make a single 68k binary, if you don't feel bothering to compile separately for all platforms, but please check that it runs well on MorphOS, OS4, and AROS/68k too. If there are some small modifications needed for different platforms, you can always detect the OS you're running on and make small changes in the code according that. Generally if it's an OS friendly utility software that doesn't bang the hw, it should run fine on those ng platforms too. I'm using many 68k programs in my daily MorphOS setup and they do work just fine there and you really can't notice any speed penalties with them.