Having noticed recently that QEmu has BSD licensed backends, I wonder if a future SDK could allow the packaging of architecture neutral binaries as a prerequisite to MorphOS 4.0. I had asked about a similar solution on Aros at one point but there was insufficient manpower at the time and with so much of the code on AROS being open source, it wasn't a priority. Also, with LLVM being the basis of WebAssembly's current toolchain and some Gallium 3D driver support, is that avenue going to be explored?

As long as we only talk about CPU/bytecode (like some Trance 2.0), I like that idea.

In a way it would bring new meaning to the “Morph” part of the name too!

Spelling things out a little more carefully, I'd prefer a statically compiled binary over a JIT. That way it compiles the rest of the way at install time. Like Dalvik, unlike Trance, it would be as fast as any compiled binary. I'll post more details later.

This really only makes sense when you have identical APIs on different processor architectures.

If applications have to be changed anyway, there is not much point, is there?

I'm envisioning a JIT-friendly ISA, engineered from ground-up to be as flexible as possible when it comes to recompiling binaries optimized to various target CPU's. Application developers use the same IDE/languages/etc as they are used to, these standard development toolchains simply compiles static bytecode binaries for this ISA instead of compiling for one of the CPU-defined ISA's. Then, at lowest possible level (so that even the OS components can be compiled in this bytecode), a JIT (kind of like Trance) recompile this bytecode into CPU native binaries, which happens only once, at first run. No virtual machine or HW emulation layers, the OS and applications running down to the metal HW native.

@ takemehomegrandma

Quote:
Please see my note above about APIs.

It has been mentioned a few times in the past that, in order to achieve features such as memory protection and proper multiprocessing capabilities, the APIs would need to be different and existing applications will need to be adapted (and recompiled).

Can't both be done?

New API, new CPU architecture, but also CPU neutral binaries so that MorphOS NG can run on new architectures without 3rd party NG devs having to recompile their code?

So MNG might have a PPC port initially, then x64 and then maybe Aarch64 in the future but 3rd party devs only need to compile once.

Does a Linux distribution have *different API's* for x86 and ARM? I thought the API was at a higher level, indifferent to CPU...?

Sigh.

I should never even have answered. My apologies to everyone.

Ouch!

Quote:

The NG MorphOS has a new API yes? Incompatible with the current API yes?

Is the NG MorphOS only ever going to be released for x64 CPU's?

If so then no point in having what I suggested, if on the other hand NG MorphOS will be available on more than one CPU architecture (ala Android for instance) then having bytecode NG applications would be something nice to have. For 3rd party devs.

What I'm suggesting is irrelevant for current MorphOS applications as they will need to be modified to use the new APIs and recompiled anyway.

[ Edited by Intuition 29.03.2018 - 15:16 ]

Calling conventions are different than regular subroutine calls. On a classic Amiga there is a libcall calling convention that says the librar handle is passed in A6 and debuggers expect the frame pointer in A5 and the heap pointer in A4 for small code models. Those need to be kept track of separately from the C calling convention where all parameters are passed in on the stack.

This needs to be maintained on a higher level than binary. I think the best way to implement it is to maintain a macro language that is implemented as a postprocessor unlike the C preprocessor. This is something that would allow some architectures to use a macro to replace trivial getters and setters also.

Is there anything else missing from the new ABI?

Now that I think about it, the macros would have to implement a VM anyway. Otherwise the pointers wouldn't be 64-bit on MOS4.x and 32-bit on MOS3.x . I still wouldn't mind a VM wrapper around the new high-level APIs.