when running on AROS, all the OS data structures an Amiga App running in that space expects to find will be present and so the App will run (just as it does on 68k AROS).
How do you solve the problem of
DWORD x=0x12345678;
char *y=hello";
char a = [(char *)&x)[0];
char b = y[0];
a is different on a big endian cpu to a little endian cpu.
Have you essentially created a little endian 68k so it will work with native AROS structures when accessing the data with the same size as it was defined? That might work in some situations, but it's trivial to create an example where it would fail.
[QUOTE="bloodline;833534]The big problem comes when trying to run the 68000 App on a 64bit processor like the x86_64, then the Amiga App can only see the first 4gig of memory, but all the the OS data structures and even the Application itself could be anywhere in a multi terabyte address space (this is address space, not simply installed RAM)... so it will fail and there is no way around this.
The 68k Amiga is firmly trapped in a 32bit world.[/QUOTE]
Where the OS structures are is irrelevant, they will contain 64 bit pointers so the offsets will be all wrong. You could however create an x32
https://en.wikipedia.org/wiki/X32_ABI AROS build.
This would have most of the benefits of x64 (see previous link) but still allow 68k code to run, potentially as well as legacy Power PC apps (if you write another emulator). If you have solved the endian issue (and I'm looking forward to your explanation) then you might be able to throw in a way of switching to x86 code as well as supporting this on x86 builds of AROS, otherwise you need an x32 big endian ABI.
You could create another method for allocating memory > 64gb for ramdisk & file system caches where you can guarantee the pointers won't need to be accessed outside the task. Which could be used on x32 builds and x86 builds using PAE.
Apple & Microsoft have gone through similar issues.
Also, how did you handle switching between x86->68k->x86 because it would be nice if exec/SetFunction could be used from both x86 & 68k code and have it be called transparently.