@Leo

Current x86 applications such as those in the Icaros distribution cannot be used on x64 AROS, partly because they are ABI0 rather than the more Amiga-compatable ABI1 (ABI0 is a legacy of the first developmental work on AROS, while ABI1 is the more modern version used for all other branches such as 68k and ARM) but also, as far as I undertsand it, becuase the internal structures for 64-bit code are different (i.e. bigger) than those for 32-bit code*.

Cheers,
Nigel.

Apolgies to any of the AROS devs reading this for the rather lame explanation here!

Sorry - double post.

Last edited by ntromans on 09-Apr-2017 at 10:16 PM.

@Leo

Quote:

Can 32bit AROS binaries execute on 64bit AROS?

No.

Quote:

If not, why?

Short answer - because 32bit AROS and 64bit AROS use totally different architectures, even if it seems to not be the case (e.g. when the CPU is basically the same piece of silicon).

Longer answer: things like WOW64 (Windows on Windows64) or 32bit support on 64bit linux rely on the fact, that today's operating systems do not share their internal structures with user space code. Therefore, an on-the-fly translation of API calls between 64bit host and 32bit application is feasible with only a tiny effort and lightweight wrapper libraries. Where necessary, larger 32bit libraries are provided which just double the functionality of their 64bit versions.

Since AROS, just as any AmigaOS-relative, happily shares all the internal structures with user space, adding support for 32bit libraries on 64bit version of the system is only slightly easier than adding support for big-endian executables on little-endian system. One could of course make e.g. a version of 32bit AROS hosted running on 64bit AROS but that's just overkill and will, most likely, never happen.

@michalsc

As recent and future CPUs are likely be 64 bit, is that means that 64 bit AROS is a brand new start of the system? Everything that was before should recompile, migrate or need to forgot?

@Lazi

Quote:

Everything that was before should recompile, migrate or need to forgot?

the current arosx86 distros and the target platform are certainly there to stay, so nothing is lost.

but whoever wants to move forward to x64, would have to accept the same handicap, abandoning the currently available software pool, at least what the sources are not available for. same situation would occure for os4 or morphos if they have attempted that.

aros simply offers that possibility already today, so this issue becomes relevant. however on the plus side, most of its software is open, so it isnt that dramatic.

@terminills

Reposting from Aros-Exec


Week of April 3rd to April 10th:
- Website / Documentation fixes (Mazze)
- ACPI button fixes (Kalamatee)
- SMP fixes (Kalamatee)
- SMP-smallpt test fixes (mschulz)
- IEEEDPDiv / IEEEDPMul implemented (neil)
- ATAPI device timing fixes (mschulz)
- genmodule 64-bit fixes (mschulz)
- stdc.library fixed (mschulz)

"The bug forces the software to adapt, evolve into something new because of it."

_________________
Support AROS sponsor a developer.

"AROS is prolly illegal ~ Evert Carton" intentionally quoted out of context for dramatic effect

@ntromans

Quote:

A minimal x86 distribution to 'play' with would be a very much appreciated stop-gap up until ABI1 is finalised and the various applications can be properly moved over to it. I just hope two* key 'external' applications, YAM and Hollywood, can make this jump successfully.

I guess you meant x86-64 or x64 (which are basically the same thing with different names).

As I stated on AROS-EXEC.org I will completely ignore ABIv1 i386 32bit AROS. With 32bit-only x86 processors becoming more and more obsolete, and almost 100% of the installed PC processors being able to execute 64bit code, recompiling everything just to fullfit the needs of the new ABI, while retaining all 32bit limitations, would be completely pointless. Icaros Desktop will keep its ABIv0 root until it will be possible, and then will switch to 64bit/SMP directly.

@paolone

If anything, it would make more sense to make a hosted version of m68k AROS. That way you could run system friendly Amiga programs on the AROS desktop, with screen, input, clipboard, file system, network, etc. integration. That's seems to be what many people are missing, i.e. running Amiga programs without UAE.

_________________
This is just like television, only you can see much further.

@BSzili

Quote:

That's seems to be what many people are missing, i.e. running Amiga programs without UAE.

but it would have to involve emulation anyway, even if hidden. thats perfectly doable today, just bundle olafs aros vision distro with pre configured uae, in anyone is really interested in it, that is.

aros68k is as such so easy to set up, copy paste the nightly and a few tweaks, much easier than os3.9 with all the boing bags, that i doubt preconfigured hosted version would make a difference.

@wawa

Of course it would be emulated, just like on OS4 and MOS, that is not the point. People seem to prefer running their 68k Amiga programs on the desktop alongside the native ones, rather than in UAE. Think of NTVDM vs DOSBox.

_________________
This is just like television, only you can see much further.

@BSzili

Quote:

BSzili wrote: @wawa Of course it would be emulated, just like on OS4 and MOS

I'm sorry, but there is nothing "just like OS4 and MorphOS" with what you are proposing. A "hosted" 68k version of AROS running on top of a native OS would effectively mean a sandbox with "virtual"/emulated H/W. In practice UAE.

What you call "emulation" in the context of MorphOS is not really emulation at all in comparison. No sandbox, no emulated hardware. The recompiled 68k binaries run in the very same memory space, handled by the same scheduler, access the same memory and registers, the same message passing, data etc, as the OS itself and any other MorphOS applications. No difference whatsoever. MorphOS (and its applications) uses Amiga 68k libraries etc completely natively, Amiga applications are MorphOS applications. And the other way around, Amiga 68k applications uses MorphOS as the native OS, the MorphOS API is the Amiga OS API. But this also means accepting the limitations and constrains brought by a 31 bit memory addressing, need of a single core 32-bit big endian CPU, etc. You can't have it all, you've got to choose. Either the MorphOS way, or the AROS way (with UAE).


Quote:

People seem to prefer running their 68k Amiga programs on the desktop alongside the native ones, rather than in UAE.

I suppose you could write a 68k translator for AROS as well (an enormous project, very time consuming and very difficult), at least for a Big Endian 32-bit CPU (and forget about the idea to easily recompile the OS for different CPU architectures after that). PPC comes to mind. But with that architecture dying, and when people are looking for a future in 64-bit and (real) SMP, it seems kind of backwards to move in the direction of all those constrains and limitations brought by Amiga compatibility, instead of moving away from that. UAE is the only reasonable compromise.

The OS4/MorphOS route made sense back at the end of the last millennium. And it has been a good ride. But as things evolved, the constrains of Amiga compatibility and the death of their choosen CPU architecture a decade ago, made them fall short of being "Amiga NG" beyond 2005. It's time for people to make up their minds. Either "Amiga Retro" or a true, future "Amiga NG" (with some UAE if needed/wanted). Being stuck in the middle makes no sense.

@TRIPOS

I didn't say anything about hardware emulation, save for the 68k CPU which is emulated on MOS and OS4 too.

_________________
This is just like television, only you can see much further.

Reposted from o1!'s report on AROS-exec:

Quote:

Week of April 11th to April 17th: - git for AROS native (Kalamatee) - build system improvements / fixes (Kalamatee) - Nouveau wait_event implemented, lock added (mschulz) - MUI autodocs improved (neil) - moved iconv to contrib (Kalamatee) - various source code cleanups for m68k/gcc-4.6 (wawa) -------------------- 1. Hold Left-Shift, Left-Alt, Right-Shift and Right-Alt 2. Hold down a function key 3. Insert a disk 4. Take the disk out

Last edited by ntromans on 19-Apr-2017 at 06:32 PM.
Last edited by ntromans on 19-Apr-2017 at 06:31 PM.

@TRIPOS

Quote:

What you call "emulation" in the context of MorphOS is not really emulation at all in comparison. No sandbox, no emulated hardware. The recompiled 68k binaries run in the very same memory space, handled by the same scheduler, access the same memory and registers, the same message passing, data etc, as the OS itself and any other MorphOS applications. No difference whatsoever. MorphOS (and its applications) uses Amiga 68k libraries etc completely natively, Amiga applications are MorphOS applications. And the other way around, Amiga 68k applications uses MorphOS as the native OS, the MorphOS API is the Amiga OS API. But this also means accepting the limitations and constrains brought by a 31 bit memory addressing, need of a single core 32-bit big endian CPU, etc. You can't have it all, you've got to choose. Either the MorphOS way, or the AROS way (with UAE).

And since when the PPC architecture was binary compatible with 68K one? I can tell you: never. In both AmigaOS4 and MorphOS there *IS* emulation at some level, or the marvel you're describing wouldn't happen. That's all. Endianess compatibility allows to reduce the emulation layer to a 68K library and little more, but neither 68k programs, nor 68k libraries would be usable on the two OSes without a translation/emulation layer. it's just less invasive than UAE is.

@TRIPOS

not full emulation of course but still 68k not runs native on it

@ntromans & @michalsc
Thanks for the explanation!

So what if tomorrow we have 128bit processors? Does it mean 32 / 64bit AROS apps couldn't run on a 128bit AROS because of the same problems?

Last edited by Leo on 20-Apr-2017 at 01:37 PM.
Last edited by Leo on 20-Apr-2017 at 11:20 AM.
Last edited by Leo on 20-Apr-2017 at 11:20 AM.

_________________
http://www.warpdesign.fr/

@Leo

Yes, of course, unless you

1. run the 64 bit operating system on the 128 bit processor, as like as we did for years running 32 bit editions of Windows or Linux on 64 bit processors (by the way, that's what AmigaOS4 and MOS should be doing on latest PPC processors)

or

2. include in the 128 bit operating system a transparent 64 bit emulation/translation layer, like 64 bit editions of Windows and Linux do for 32 bit applications (google for syswow64 for some explanation)

Approach #2 would be overkill for AROS but not impossible at all, simply put: it's too much effort for the too less arms available at the moment, and binary-only applications for AROS without available sources are rather scarce. So we can recompile them for the new architecture and live happy.

What if AROS64 added memory protection to be a real mothern platform and emulated 68k in a way that the user would not notice.
Sure it would break everything regarding compatiblety with Amiga, MorphOS or AROS32 software, but at the same time it could gain so much intrest that in the long run we would see hell more software for our platform + very mothern advanced apps. + developers and users outside amigaland.
If could be a distro running Linux to support all kind of drivers and running AROS64 like in vmware, but of cause set up and ready to go.
For sure I would also like to see at least one dedicated mashine (laptop) possible to buy where it ran native.

Last edited by nikosidis on 20-Apr-2017 at 12:40 PM.

@nikosidis

that would come at a price... software would no longer be easy portable between the platforms, there would be AROS64 on one side and all others at the other side

@OlafS25

Quote:

that would come at a price... software would no longer be easy portable between the platforms, there would be AROS64 on one side and all others at the other side

So? whats's the difference? software has to be recompiled anyway. It is AROS64 and all the others in different sides anyway. I was forgetting about memory protection, but it is a crucial feature.