@matthey
Quote:

I hope "that level of [68k] compatibility" is not required as we don't know if it is possible yet on the Raspberry Pi. Michal hasn't said anything about finding a way to enable big endian support without using a deprecated instruction. A compatibility breaking little endian AROS ARM port for the Raspberry Pi probably makes more sense otherwise. Big endian hardware is a dying breed and 68k compatibility is much less efficient without it.

For the newer 64bit pi, setend is gone, not just deprecated.

You can set the data endianness using a bit in the system control register though. You could set this early on and just leave it as far as I can tell.

The instruction endianness is always LE, but that doesn't really matter as long as the data structures are BE for 68k code to access.

Edit: I found one of the reference I remembered:

http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.den0024a/BABEGIJE.html

Quote:

This data endianness is controlled independently for each Execution level. For EL3, EL2 and EL1, the relevant register of SCTLR_ELn.EE sets the endianness. The additional bit at EL1, SCTLR_EL1.E0E controls the data endian setting for EL0. In the AArch64 execution state, data accesses can be LE or BE, while instruction fetches are always LE. Whether a processor supports both LE and BE depends upon the implementation of the processor. If only little-endianness is supported, then the EE and E0E bits are always 0. Similarly, if only big-endianness is supported, then the EE and E0E bits are at a static 1 value. When using AArch32, having the CPSR.E bit have a different value to the equivalent System Control register EE bit when in EL1, EL2, or EL3 is now deprecated. The use of the ARMv7 SETEND instruction is also deprecated. It is possible to cause the Undef exception to be taken upon executing a SETEND instruction, by setting the SCTLR.SED bit.

Last edited by Wumpus on 30-Aug-2018 at 08:43 PM.