The 64-bit underlying operating system will be incompatible with ApolloOS unless the 32-bit compatibility layer is developed separately as a compatibility shim.  That being the case, breaking from the traditions of the past could bring an advantage or two.
 
  1. AmigaOS cannot use full SMP without breaking compatibility anyway.  The scheduler was documented as blocking lower-priority tasks.  This means no multicore 68090 without a second layer of OS.
 
  2. AROS can only be 64-bit capable at a source-code compatible level.  Binaries made from earlier years cannot be transparently made 64-bit.  Message passing is done by absolute address on both AmigaOS and ApolloOS, for example.  Another example is jump table entries on shared libraries.

What the competition has done:

  Windows 32-bit executables are run using a compatibility shim called WoW (Windows on Windows).  64-bit Windows executables are a totally different file format.
 
  Mac used "fat binaries" where multiple formats are included in a single bloataed executable format.
 
  Linux disavows 32-bit compatibility unless all the supporting libraries are also 32-bit.  Ugh!
 
  MorphOS uses a JIT compiler for each formerly native executable format on a compatibility breaking Q-box for the x86-64 Quark Microkernel gaining both SMP and 64-bit in one step.  64-bit x86 retains no knowledge of 32-bit x86 nor is PPC64 ever supported.
 
  AmigaOS 4.x is trying to splice in nonsymmetric multiprocessing but no hope of 64 bit addressing.
 
  AROS x86-64 is not backwardly compatible to 32-bit x86 AROS binaries at all.  Since compatibility is already broken, why not add in SMP?  Sure!
 
  Now that you see how much effort migrating to 64-bit operating systems is, is anyone willing to put forth the effort of making it happen?

It's not like Vampire is powerful enough to run those stupid unoptimized web browsers anyway.

I should have made my last statement clear: nobody should go to that level of effort just to "keep up with the Joneses".  Also, SMP and multicore CPUs can't fit on an FPGA cheaply.

Also, Bartman's GCC12 port needs runtime support.  If that could be brought up to a level to compile AROS, we'd be in better shape for ApolloOS also.

eric gus wrote:

Not that I would stop anyone from doing this but I don't know what the payoff would be putting this effort it at this specific point in time (note im not saying its a bad idea, im just saying its a bit early to be thinking about this with the work still to do) .. Maybe we shelve the idea and revisit it when ApolloOS is more refined and polished. Its valid, I just think its a bit premature. Having a fully 100% compatible to classic AmigaOS, ApolloOS would be a great starting foundation to build this idea on, but we need to get there first.. and that will take some time and focused effort.

I agree to a point.  Classic AmigaOS is built on the same crumbling foundation as AmigaOS 4.  It will eventually run out of gusto.

I've pretty much moved on from AmigaOS.  Haiku is my new foundation and the operating system by itself needs 128 MB of RAM.  Most of that is for MMU page tables but SMP is definitely there.  Would refitting Haiku to run using an Apollo-style memory protection unit be practical for a first-tier of operating system?  It's written mostly in C++.  One Haiku developer tried compiling Haiku on an A4000 with 128 megs but didn't make it very far.  So far there is little interest in running Haiku on a single-threaded system.

Why would we be in a better shape?

Is the 68K code generation of it better than GCC 6.5?

Yes.
But did you review the 68K Assembler code generation?
Is GCC 12 producing better or worse code?
In the end the quality of the generated code is also very important.

It happened before that higher number GCC did in fact produce less good 68k code - so it makes sense to verify this.

Did you do this by chance?