michalsc wrote: with SMP AROS would need to break compatibility. On x86_64 we use spinlocks in many weird places (like e.g. inside struct MsgPort, aligned on cache line...) so that sizeof some structures changes.
Wasn't that a quick and dirty implementation as a proof of concept? How long can that spinlock busy wait? There is no lock free/non-blocking algorithm? You can't do a core task/thread Switch() while waiting?
Of course there are all kinds of issues with trying to keep compatibility on foreign hardware without sandboxing. The FORBID/PERMIT (less common ENABLE/DISABLE) macros from exec/ables.i are common in 68k code and in AmigaOS 3.
a6=ExecBase addq.b #1,(TDNestCnt,a6) ; Forbid without Forbid() subq.b #1,(TDNestCnt,a6) ; Permit without Permit()
If it is not possible to convert to big endian mode early (bootloader), then it should be possible to convert to big endian mode with the following instruction.
SETEND BE
The problem is that the instruction is deprecated in ARMv8 even though it is usually available on current ARMv8 hardware. The next Raspberry Pi may not support it which would be embarrassing and catastrophic to an ARM AROS port depending on it. Also, the instructions remain little endian which makes it feel like a kludge for debuggers, disassemblers and other development tools. Compilers and development tools will need a proper big endian ARM target or require many switches to get BE data with LE code. It would probably be best to break compatibility and do a proper LE port of AROS for ARM with SMP. I know how important software compatibility is but preserving compatibility and adding modern features would be difficult enough with a BE CPU and custom hardware.
AmigaOS on LE CPU - Sandbox compatibility only but modern features like SMP are possible AmigaOS on BE CPU - Compatibility without modern features or sandbox with modern features AmigaOS on custom BE SoC (CPU+Amiga custom chips) - Best chance for compatibility and features