@matthey

Quote:

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.

as you might have red (or maybe it was tim that pmed me about it?), one of the reasons michal picks up on this project is that newer compilers apparently offer opportunity to define endiannes on the fly, so aros structures can be effectively turned to be big endian, and therefore be made compatible with amiga. which would allow the same approach on running 68k code within aros on arm as os4 and morphos do. im not sure about little endian archs.

thats at least, how i get it.

Last edited by wawa on 25-Aug-2018 at 08:28 AM.

@matthey

Quote:

matthey wrote: Quote: 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() http://amigadev.elowar.com/read/ADCD_2.1/Includes_and_Autodocs_2._guide/node007B.html Maybe it could be dealt with by making the ExecBase pages read only in user mode and having the MMU kernel fault handler suspend/restart all cores?

Let's see... The Page fault handler sends IPI (Inter-Processor Interrupts) to all cores in the system, each IPI handler atomically increases a counter and then goes into a spinloop. The Page fault handler waits until every core have started spinning and then returns to the program making the memory access. Add a permit() path that unlocks all spinning cores and it could perhaps work.

But what about handling disabling/enabling of interrupts? Sure, one could run all code in user mode and trap attempts to manipulate the bit doing something similar as the above...

I think there will be huge overheads. May be acceptable, haven't programmed modern ARM cores so don't know.