@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

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.