Quote:

wawa wrote: 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.

Do we really want to mark all the AROS source code structures with (CPU/AROS port specific) BE/LE identifier tags? The compiler supporting ways to identify big endian data is only half the battle (it is possible to create SETENDBE and SETENDLE assembler inlines for C which would accomplish much of the same goal). We need to examine the performance and future compatibility of such solutions. I know of 2 ways to keep the data in BE orientation under AArch64.

1) Use SETEND BE and SETEND LE instructions.
Performance: Very good (switch to BE and rarely have to switch back to LE)
Future compatibility: Poor (SETEND is deprecated in ARMv8/AArch64)

2) Lacking BE/LE load/store instructions, REV, REV16 and REV32 instructions would be used.
Performance: fair (these REV instructions will be required after and before every BE load/store)
Future compatibility: Excellent (the REV instructions are here to stay)

There may be a 3rd way to set the endianess early which would behave much like solution #1 but hopefully with a brighter future. Even if this is not possible, some ARM hardware may not support BE making an AROS LE port more attractive. ARM may advertise that it is bi-endian but it is more LE much like PPC is bi-endian but more BE (although PPC/Power LE support has been improving).