@wawa


Quote:

since you bring up arix, which i support, even if it isnt of an essential interest for me as a m68k -amiga troll, the development, if open, will likely be taking place on your github account, since there is no agreement as of if merging arix back into aros trunk as a target is desired.

Where in this thread did Michal bring up Arix? Arix was nothing more than a Linux-hosted version of Aros with much of the underlying Linux bits, i.e. the package manager, etc, stripped out. Aros ran on top of a shim or API translation layer. The Arix project was completely dead from its inception. Back in 2013, I agreed to be a beta tester and was asked to sign an NDA but after the NDAs were signed and returned, the project died off completely. It was very unstable and would lock my system up completely at random. The project turned out to be a total waste of time.

The Arix OS page on FaceBook is also a sham. The last update/post there is for the SMP version of AROS and was posted well over a year ago https://www.facebook.com/Arix-OS-414578091930728/

@wawa

Quote:

is there any more specific plan how to proceed

The plan is to proceed as always when I was working on AROS port to new architecture. :)

Quote:

there is no agreement as of if merging arix back into aros trunk as a target is desired.

It cannot be merged, it's a completely different project. AROS port to big-endian arm will be first synced to my github aros repo and, when ready, synced back with AROS tree.

Quote:

now , there was talk about some special new version of compiler that is required feature wise for your intentions to explicitely compile aros internal structs big endian. what compiler is it? clang?

No, it's gcc. The gcc compiler has special flag as well as attribute/pragma which can force selected structures to be explicitly big-endian or little-endian, independent on current CPU endianess. It works perfectly when you write/read data in such structures but fails already when trying to get a pointer to a field within struct. It means, already all list operations (macros from exec/lists.h) will fail to compile.

Therefore I've abandoned that idea and move forward with real armeb (eb == endian big) target for AROS.