@Wumpus

Quote:

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

Yes, in 64bit mode it is gone. In 32bit mode setend is still available.

Quote:

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.

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

@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.

@gregthecanuck

Quote:

My understanding is that AROS on RPi: - runs 68K applications through emulation (UAE?)

Currently available AROS for RPi runs in little-endian mode and, therefore, is per definition binary incompatible with AmigaOS and as such can run 68k applications in UAE only.

My aim is to make AROS for RPi which runs in big-endian mode where all system structures are binary compatible with AmigaOS. This gives us a chance to try to integrate a m68k emulation in system, just like petunia on OS4.

Quote:

- is still API compatible with the OS3.1 SDK?

Yes, that is one of AROS aims. To be API compatible with AmigaOS on *all* platforms.

Quote:

- but there are different ABI versions?

The old, V0 ABI is relevant to x86 targets only. All other targets should be already abi v1. The 32 or 64-bits or SMP/no SMP have nothing to do with ABI version.

@michalsc

Quote:

michalsc wrote: @Wumpus 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?

What could we help with?

Gratz Mschulz :)

@Wumpus

Sure is AROS kernel. No linux stuff with the AROS Pi project :)

Last edited by nikosidis on 05-Sep-2018 at 04:23 PM.

@Wumpus

Quote:

I'm a little confused on whether this is ARIX with a Linux kernel or AROS kernel on bare metal though.

This is about AROS kernel on bare metal in big-endian mode. ARIX is totally unrelated :)

Quote:

And when could we poke around ourselves if we're willing to potentially submit changes?

I will publish all changes to my local repo on github and once it is working as expected I will sync with AROS main repository again. But at the moment there's not much you can help with. I have to build as much of AROS as possible first :) You can follow the progress here on patreon.

@michalsc

Quote:

It cannot be merged, it's a completely different project.

i have initially had an impression, based on it being branch in jasons repo, that arix could be remerged into aros and wondered if this would be good and desired, but its good to hear that you and nick agree in this respect. lets forget that.

Quote:

No, it's gcc

but some recent version i have been told, or is it an option with aros current default, gcc4.6.4?

Quote:

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

so you resign on moving aros structures to big endian no matter what architecture (as i understand it was the original plan?). pretty ambitious, a shame it didnt worked, it would give a chance using 68k binaries on whatever aros platform, right? so aros structures remain being held in native endianness. instead the plan is now an arm specific big endian aros port.

Last edited by wawa on 05-Sep-2018 at 05:52 PM.

Arix, from what I understood has little to do with AROS.
It is more of a new project using Linux kernel and based on many ideas from AmigaOS
Wanderer will not run on Arix right?

If so there is very little chance that project will succeed and it will take many years before useful.

Quote:

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.

@matthey

Quote:

Congrats on your progress.

Thanks. I'm trying to do my best.

Quote:

Are the executables using Thumb2/ARM32 or AArch64?

They are arm32 executables. I was thinking about aarch64, especially about using the ilp32 mode on aarch64, where int, long and pointer are all 32 bit. This could give us some advantages of 64-bit ARM, like 32 general purpose registers and ability to do 64bit math in single register, whilst keeping the whole 32 bit compatible. The problem is however extremely scarce support for ILP32. There are some people at linaro working on this but there is no code in main repositories of binutils or gcc yet. So no, I wouldn't like to try that. Aarch64 port of AROS yes, some day, but not with 32bit simulated in 64bit mode.

If whole toolchain would be completed (in main repositories and stable) I would consider it though ;)

Quote:

The Raspberry Pi doesn't have enough memory to need 64 bit support

The memory doesn't matter that much. For a long time I was thinking about misusing 64bit address space for other purposes, even if amount of physical memory is not that large.

Just think about single address space where each task gets it's own 2GB slot (or multiple of 2GB slots) of virtual memory, with stack going downwards and expanding if necessary...

@michalsc

OK, thanks.

I've seen ARIX mentioned a lot here and on your Patreon page, so it's hard to tell exactly what the plan is.

@Wumpus

Quote:

I've seen ARIX mentioned a lot here and on your Patreon page, so it's hard to tell exactly what the plan is.

There are two projects I'm working on.

1. I'm attempting to port AROS to RaspberryPi (again), but this time the ARM CPU in Pi will be running in Big Endian mode so that I can try to maintain binary compatibility with AmigaOS. This is raspi-armeb AROS.

2. In parallel I'm working on my small project, where I try to build set of libraries with AmigaOS-like API, allowing one to write software for Linux which looks and behaves like Amiga software. The project is independent on AROS and compiles to every target where linux kernel can run (I'm testing it on x86_64 and on RaspberryPi). This is ARIX.

@michalsc

Quote:

The problem is however extremely scarce support for ILP32.

So what are the alternatives -- LP32, LLP64, LP64, or... something else?

Quote:

2. In parallel I'm working on my small project, where I try to build set of libraries with AmigaOS-like API, allowing one to write software for Linux which looks and behaves like Amiga software. The project is independent on AROS and compiles to every target where linux kernel can run (I'm testing it on x86_64 and on RaspberryPi). This is ARIX.

I shall be following this with great interest!

Last edited by bison on 05-Sep-2018 at 09:04 PM.

_________________
"Unix is supposed to fix that." -- Jay Miner

@nikosidis

Quote:

Wanderer will not run on Arix right? If so there is very little chance that project will succeed and it will take many years before usefu

it does as certainly any/most aros software for the same architecture. arix is something like highly integrated aros hosted with an invisible host.

@wawa

errm, at least as i understand it. i dont have enough interest for it thugh. admittedly.

@wawa

Quote:

it does as certainly any/most aros software for the same architecture. arix is something like highly integrated aros hosted with an invisible host.

It's not the arix you know from Jasons github repository. That one was an intermediate step between regular AROS hosted and something more tightly bound to the linux. What I'm working on right now is something completely different.

It may look the same, just like here:
Quote:

PutMsg(arixPort, &msg); WaitPort(reply);

but if you look more carefully, you will notice differences, like mixed calls to arix libraries, linux syscalls or glibc:

Quote:

printf("doing %d iterations\n", NUM_ITER); clock_gettime(CLOCK_REALTIME, &t0); for (i=0; i < NUM_ITER; i++) { PutMsg(arixPort, &msg); WaitPort(reply); DiscardMsg(GetMsg(reply)); }

Finally, if you look at the whole you will notice that the messages are passed by value through an unix socket, not by reference as on AmigaOS, as they are crossing a boundary between two linux processes. Even more strange, the arixPort is not a pointer to a struct MsgPort because it cannot be (the MsgPort was created in another process). Instead, there is:
Quote:

uuid_t arixPort = MAKE_UUID(0x00000001, 0x0000, 0x4000, 0x8000 | NT_MSGPORT, 0x000000000000);

To some degree it is source code compatible, but only where possible. Where not, I do not hesitate to redesign API and break compatibility totally.

Quote:

michalsc wrote: They are arm32 executables. I was thinking about aarch64, especially about using the ilp32 mode on aarch64, where int, long and pointer are all 32 bit. This could give us some advantages of 64-bit ARM, like 32 general purpose registers and ability to do 64bit math in single register, whilst keeping the whole 32 bit compatible. The problem is however extremely scarce support for ILP32. There are some people at linaro working on this but there is no code in main repositories of binutils or gcc yet. So no, I wouldn't like to try that. Aarch64 port of AROS yes, some day, but not with 32bit simulated in 64bit mode. If whole toolchain would be completed (in main repositories and stable) I would consider it though ;)

ILP32 looks pretty good for the Raspberry Pi. Yes, it avoids the performance loss of 64 bit pointers while gaining the performance enhancements of AArch64 (much like x32 for x86_64 hardware). LP64 is not very good for AmigaOS 32 bit compatibility. It would be most interesting if ILP32 and LLP64 code could execute together in AArch64 mode (pointers could be 32 bit or 64 bit) with a few tricks but LP64 seems to be the common data model for AArch64.

Quote:

The memory doesn't matter that much. For a long time I was thinking about misusing 64bit address space for other purposes, even if amount of physical memory is not that large. Just think about single address space where each task gets it's own 2GB slot (or multiple of 2GB slots) of virtual memory, with stack going downwards and expanding if necessary...

I don't think you need a 64 bit address space for this unless you have more than than 2 GiB of memory. I have thought about the same thing but you would probably need to leave some shared/public memory mapped to all tasks for compatibility.

@matthey

Quote:

I don't think you need a 64 bit address space for this unless you have more than than 2 GiB of memory.

Yes, but then you need to try to shrink the slots per app as much as possible. Plus, keeping this all in tiny 32bit address space means, there would be no chance for features like automatic stack expansion.

On the contrary, doing the same on 64bit target means you have 131072 2GB slots (in case of 48 bit virtual address space) which you can assign to tasks/processes. Having plenty of address space means also, you can just waste MMU pages for stack expansion and other goodies.

Quote:

michalsc wrote: There are two projects I'm working on. 1. I'm attempting to port AROS to RaspberryPi (again), but this time the ARM CPU in Pi will be running in Big Endian mode so that I can try to maintain binary compatibility with AmigaOS. This is raspi-armeb AROS. 2. In parallel I'm working on my small project, where I try to build set of libraries with AmigaOS-like API, allowing one to write software for Linux which looks and behaves like Amiga software. The project is independent on AROS and compiles to every target where linux kernel can run (I'm testing it on x86_64 and on RaspberryPi). This is ARIX.

Very interesting, both of them. Is there some long term plan to offer Intuition and workbench for ARIX?

@hth313

Quote:

Is there some long term plan to offer Intuition and workbench for ARIX?

That's very long term but yes, I want to go as far as possible with it, including gui.