MorphOS on x86???

[itix]

Problem there is that you must drop all existing software.

[itix]

@warpdesign

Problem there is that you must drop all existing software.

There is a wonderfull piece of software called UAE... And guess what, it runs on x86! And guess what, it allows to run more software than any AmigaOS will ever run natively...

(Win)UAE is not an operating system. But maybe you meant that MorphOS could map all memory on x86 as big endian and run 68k software natively.

Without the software MorphOS is like Windows NT on PPC. Nice to have but completely useless because there is nothing to run.

We would compete with Windows

Really ? Is MorphOS competing with Linux on PPC ?

Actually MorphOS competes with Windows all the time.

[itix]

You're better off with AROS running in little endian on x86 with an emulator running AROS on 68k that transparently links the two environments.
 
You'll never achieve an x86 kernel that can run x86 or 68k software that automatically can link to either a 68k or x86 library.

Amithlon can execute 68k and x86 code and binaries can link to each other.

http://www.amigahistory.co.uk/emulators/amithlon.html
http://aminet.net/search?arch[]=i386-amithlon

But here x86 binaries are using modified compiler where endianess is swapped automatically (IIRC?).

[itix]

You can't have a single library base that can be called from x86 or 68k.
 
The only option would be to have all library bases called as 68k and have a switch from x86->68k->x86 when you called an x86 library from an x86 piece of code. However this would introduce a huge overhead for every call.

The overhead is tiny. In MorphOS all old AmigaOS API calls are called as 68k from PPC code and the overhead is negligible. Overhead is so small that even OS4 cant beat it with interfaces.

You would also have to include a 68k stub when using SetFunction(), so the code would not be source compatible. You can't call a different function as something might have SetFunctioned SetFunction(). You can't have a different library base for 68k and ppc programs as the libraries data is also stored in the library base.

Anyway, good luck.

SetFunction() is trivial. In MorphOS you can patch 68k functions by PPC or 68k code. You have to include a 68k gate to install PPC native patch but internally 68k code is never executed in PPC -> PPC calls. PPC native patches run without performance loss and on the other hand 68k SnoopDos is fully functional in MorphOS if you dont happen to have PPC native port on your HD.

Not being source compatible doesnt matter. You cant port MCP or MCX or SnoopDos from 68k to PPC or x86 or ARM without making changes to patch code. In 68k arguments are passed in 68k registers and they often involve hand written machine code.

[itix]

It's got to execute the 68k gate, because it doesn't know what the code is doing. You can dynamically recompile it, but you've still got some lookups to do to find the native code.

It has to check if 68k gate is there: if it is then it can directly continue executing PPC code. If 68k gate is not found then system switches to 68k emulation. No need to dynamically recompile anything. The 68k gate is just 68k trap instruction and pointer to PPC code. Application writers dont have to care about it. It is all embedded into operating system.

Or you can put some heuristics in to find a standard gate and shortcut it. It's not just old libraries that this would have to happen for if you want to be able to drop ppc libraries in and have them used by 68k software. It could be any library that has ever been written.

Calling PPC code from 68k is really simple and extremely efficient. All PPC native 68k ABI calls have 68k gate with 68k trap instruction. When trap instruction is executed emulator switches to direct PPC execution mode.

It is easier than you think.

You can write libraries completely in C, I wouldn't like to say how often in occurred but you don't need assembler at all (just compiler support for regparm).

All 68k libraries written in C I have ever seen always use some reg(a0, foobar) style argument passing which will not work on non-68k compilers.

The next problem is that we're actually talking about x86 not PPC. So all of your code is going to have to do endian conversions. You either go the amithlon route, but then software that needs to write little endian values will end up doing two conversions. Or you spend the rest of time changing code to do the conversion where necessary. Or you try to come up with a new compiler patch that allows you to selectively have little or big endian variables.

Endian conversion of course is real issue on x86 it will be faster than WinUAE or any real Amiga.

Because of the amount of effort, still being limited to single processor and no memory protection, how horrible all the compromises would be to get it working on x86 it's not going to happen. I can't see developers flocking to an operating system that is crippled with that amount of backward compatibility. You can't even support x64.

Of course cant and if MorphOS switched arch it would most likely drop all 68k (and PPC) binary compatibility including use of 68k gates.