Yes, it is ok, but is's still total madness. When compiling for big-endian mode of ARM (the currently supported BE8 with BE data and LE instructions) the toolchain makes following: 1. First 32-bit big endian object files are created. *Both* data *and* instructions are big endian. 2. In last stage of building executable the linker is run with --be8 parameter. During linking stage *all* cpu instructions in the object files are byte-reversed to LE mode, whereas data is kept in BE.
I've spent last few days at trying to integrate that into AROS toolchain, together with fixing our gcc/binutils patches which did not understood difference between arm/armel and armeb targets.
Anyway, problems solved. AROS toolchain for big-endian arm is there and it is working now :D
That's total madness. I guess if it works though lol
I'm a little confused on whether this is ARIX with a Linux kernel or AROS kernel on bare metal though.
And when could we poke around ourselves if we're willing to potentially submit changes?
michalsc wrote: Yes, it is ok, but is's still total madness. When compiling for big-endian mode of ARM (the currently supported BE8 with BE data and LE instructions) the toolchain makes following: 1. First 32-bit big endian object files are created. *Both* data *and* instructions are big endian. 2. In last stage of building executable the linker is run with --be8 parameter. During linking stage *all* cpu instructions in the object files are byte-reversed to LE mode, whereas data is kept in BE.
I've spent last few days at trying to integrate that into AROS toolchain, together with fixing our gcc/binutils patches which did not understood difference between arm/armel and armeb targets.
Anyway, problems solved. AROS toolchain for big-endian arm is there and it is working now :D
Congrats on your progress.
Are the executables using Thumb2/ARM32 or AArch64? It would be interesting to use AArch64 mode as there are more features. The AArch64 ISA was smart to keep 32 bit operations which may allow 32 bit compatibility in 64 bit mode (like a CISC ISA but unusual feature for a RISC ISA). Clearing all of the whole 64 bit GP registers on task creation and using only 32 bit operations should give 32 bit compatibility in 64 bit mode. Do not use the upper (negative) 2 GiB of 32 bit addresses without figuring out a way to sign extend 32 bit pointers to 64 bit pointers (traditionally unused in AmigaOS and would require MMU relocation on the Raspberry Pi). Using AArch64 mode may allow some 64 bit support and BE 68k compatibility at the same time. The Raspberry Pi doesn't have enough memory to need 64 bit support but AROS on other AArch64 hardware would be more interesting.