I seel "Silly-SMP" as an exercise in 1) seeing how far you can get *while* retaining compatibility
No exercise needed to see that it won't be neither binary compatible (had it been running on AROS 68k on non-existent dual CPU 68k HW), and it won't be source code compatible to anything and everything written for AmigaOS3.x either. You would be required to not only recompile the applications, but also adapt the sources (more or less, depending on the app in question).
Have a look at
this post in particular, and threads like
this and
this in general, and you will see that:
1) Full Amiga legacy compatibility is *impossible* to begin with
2) and *on top of that* there are lots of hurdles to overcome and performance penalties to pay, if you *persist* in going this way despite the fact that you have already broken compatibility and a rebuild of the SW base will be required anyway (hence an opportunity to introduce a SMP model that is more *real world tried* and less "silly").
2) exposing what code actually needs to be fixed.
What you can "fix" is to overcome as many of the hurdles as possible and trying to make performance as good as possible. This is what real life testing/developing of this concept can provide. But per concept (visible in the first link above), no "code fixes" can make this fully Amiga compatible.
A lot of the "SMP is impossible" whining in these discussions
Oh please, this is not "whining". Amiga can't be SMP, per design, per concept.
is based on a "worst case" scenario where Amiga applications runs rampant all over memory and uses every dirty trick in the book all the time *and can't be fixed*.
But here's the thing:
We have a very limited software catalogue. Even on classic. *Most* of those applications are going to interact with the OS in ways that breaks simple approaches to SMP in very limited ways, that can either be worked around, or patched.
Some are going to be very problematic, and you then have a few alternatives: Fix them, especially if you have the source; add hacks to work around them (up to and including "blacklisting" these applications and cause the OS to do nasty hacks when they run, up to and including sandboxing them in some way or another); or accept that they never will work outside of emulation or with SMP turned off.
But the thing is: We don't really *know*. We do know that cache coherency will be an issue for anything that tries to meddle with system structures. We do know that frequent Forbid()/Permit() would be a problem, especially if we're forced to forbid across all cores and flush caches. But we don't have accurate measures of how much software is affected how badly.
No, no, no, either it's
100% compatible, or it's
NOT! There is *nothing* in between! It's purely digital, either
1 or
0, it's either
fully black or
fully white. Purposely building an OS that sits in the grey scale between black and white will mean that its applications will be running in a mine field; Some may perhaps run, some longer than others, but there are no guarantees whatsoever. This is simply not serious, it would be a joke, and any OS developer who thinks that "less than 100% compatibility/stability" is OK and actually something to *aim for*, shouldn't be taken seriously as well!
That doesn't mean that "Silly-SMP" isn't a cool thing or an interesting experiment. Which is its purpose AFAIK - being a research experiment. But it will never be a realistic or good way of bringing SMP to AROS/ARIX.
It is possible the best approach is to sandbox all old apps in an emulator and let them continue running on a single CPU, and bridge various things to the host OS.
It will be the *only* way to run legacy Amiga/AROS apps in a new, SMP enabled system. Like AROS already does with UAE. Old Amiga 68k binaries can run there, and existing/old AROS/Amiga sources can be compiled for it unchanged. The same will be for Hyperion's "X Kernel", or when MorphOS goes "4.0". When the "NG OS's" goes "NG 2" and introduces things like SMP, 64-bit, etc, this is simply the way it has to be.
But this is slightly off topic in this thread anyway, since apparently,
ARIX will not be SMP!
