@wawa

Quote:

>> he means if X86 apps run on X64 propably i dont think this is how this works or is envisioned. aros has distinct separate platforms for separate architectures. windows or linux may provide x86 environemts on x64 systems to run legacy software transparently. such a necessity doesnt exist on aros (or other amiga ng platform for that matter). there is no notable pool of software that isnt open source and could not be natively recompiled for another target platform.

The question is incredibly complicate for AROS.

First of all, let's clarify that neither Windows nor Linux "can" run 32 bit applications on their 64bit flavours. They both provide a transparent translation layer (for ex. SysWoW64 for Windows) which provide compatibility to legacy 32 bit software. It's something as transparent as 68k support on AmigaOS 4, but technically much more complicated.

When talking about AROS, we need also to keep different, binary-incompatible ABI versions in mind.

Now we have all legacy applications compiled for ABIv0 i386, and almost zero for ABiv1. AROS for x64 is ABIv1 only. This means that when you take a compatibility layer under consideration, you must keep in mind that this layer must also support a different ABI than the host OS. So the question is: would it take much more effort/time recompiling all AROS ABIv0 i386 applications to ABIv1 x64, or to develop such compatibility layer? For what reason, by the way?

Please notice that, once ABIv1 will be declared stable, I - and I guess also olther distributors - will probably switch to x64 for further developments, even if this will mean loosing something in the first months. Having all applications recompiled to x64 will take MUCH time and there will be conditions were this will be impossible, but at least the available ones will be stable and perfectly integrated in the new environment. 68K Amiga apps will always run through UAE.

@paolone

By "legacy" I mean apps that do not use any AROS specific APIs, because you need to use new APIs to have full 64bit/SMP support, right ?

_________________
http://www.warpdesign.fr/

@Leo

no on Aros you have everywhere the same API (at least in theory) so you just recompile it. I am not sure if that fully works for 64bit though. But you have the same APIs everywhere. What you refer with special APIs for SMP is I think called AMP and is no real SMP. That is what is planned for AmigaOS, no difference for user as long a application not is adapted for it. What the Aros devs are working on is automatic so everyone benefits of more than one core.

@paolone

when you will add the virgl support i will more happy

_________________
I love Amiga and new hope by AmigaNG
A 500 + ; CDTV; CD32;
PowerMac G5 Quad 8GB,SSD,SSHD,7800gtx,Radeon R5 230 2GB;
MacBook Pro Retina I7 2.3ghz;
#nomorea-eoninmyhome

@Leo

Quote:

apps that do not use any AROS specific APIs

you mean portd from other systems? thats again all the same for all amigaoid-ng systems. say linux (most of them), genuine amiga (second, cause of legacy) and probably morphos (thanks to odyssey frontend to webkit and few other rather unique achievements, due to explizit numbers of able coders morphos has apparently gathered for the time being).

as on other systems there is handfull of applications that use the exclusive features (are there any actual useful advantages in comparison to todays standards? dont point me to rexx any more, please).

other than that aros contributors have an adavantage to actually be still around, unlike most else amiga-(ng9 contributors. i have just lately filled some reports of what i found a problem with gcc6.x compilation (all valid issues) and had the source updated within two days (upstream).

@OlafS25

Quote:

on Aros you have everywhere the same API (at least in theory) so you just recompile it.

you can recompile them. if you cant, there is a bug. for instance a function lacking necessary register paramatrizing. such functions though ususally receive appropriate macros (probably just in case) even on platforms actually independent from it, at present.

Last edited by wawa on 27-Feb-2017 at 07:02 PM.

@OlafS25
Quote:

no on Aros you have everywhere the same API (at least in theory) so you just recompile it. I am not sure if that fully works for 64bit though. But you have the same APIs everywhere.

The main problem of porting things to 64bit, that there's a lot of Amiga app source code out there, and even some API concepts (taglists come to mind), which assume that the size of a pointer is 32bit, so it converts pointers to ULONG types and vice versa. That doesn't work at all, on 64bit, and such code has to be fixed. AROS introduced a new type, IPTR, which should be a pointer-sized integer, everywhere, to aid fixing such conversions. But then the source has to be modified to take advantage of this. But this is an AROS-ism, not part of the original Amiga API, and it is not adopted by other Amiga-like systems (yet?), which might introduce other problems.

All in all, depending on the style the software was written in, it's might not be trivial to do a 64bit port, while keeping the compatibility with the original.

Also, talking from experience, the 64bit AROS port is not so mature yet. There are basically no end users on 64bit, so you end up with a bunch of missing or broken features which no one noticed. Although it got better lately, but still way to go...

_________________
MorphOS, classic Amiga, demoscene, and stuff
"When a bridge is not enough, build a Viaduct!"
"Strip the Amiga community of speculation and we can fit every forum on a 720k floppy" (by resle)

@Chain-Q

Simply put: need for adapting is the price for evolution. Or are current windows program coded like in 3.1 era?

Sigh. Doubled post...

Last edited by paolone on 27-Feb-2017 at 09:38 PM.

@Chain-Q

Quote:

AROS introduced a new type, IPTR, which should be a pointer-sized integer

in respect to other source incompatibilities like those introduced by os4, this is rather trivial to track and easy to fix. expacially the source using IPTR will still be amiga compliant, where IPTR simply defaults to be defined as ULONG. right?

@paolone Quote:

once ABIv1 will be declared stable, I - and I guess also olther distributors - will probably switch to x64 for further developments, even if this will mean loosing something in the first months. Having all applications recompiled to x64 will take MUCH time and

Oh dear. I thought people would have learnt by now (there are enough examples over the decades) that an attempt to force a transition to an incompatible "improvement" just results in many people not upgrading at all (and potentially driving them away to competitors), thus destroying whatever market share you had, particularly when there is zero apparent benefits to the end user. (I now expect lots of explanations about why 64-bit is soooo much better... Which will entirely miss the point.)

I mean, OS4 or MOS could have easily gone 64-bit or SMP themselves, but they'd have had to drop their 68k compatibility (and most likely compatibility with existing PPC apps), which would result in approximately zero apps (compared to what they currently have) & a market share approximating zero.

And from a cross-platform developer point of view, one of the reasons I still manage to support AROS (to some degree) is that AROS is basically source-code compatible with OS3.x (along with OS4 & MOS). I fear that changing AROS to 64-bits will make it almost impossible for me to support AROS, while also simultaneously supporting OS4 & MOS, and so I will have to completely drop AROS.

The change from ABIv0 to ABIv1 on it's own would have been bad enough, but "merely" a recompile for 99.99% of programs, and I guess that (for example) it wouldn't be too hard for AmiDevCpp to get updated to support it. I am doubting that changing to 64-bit will be anything like as easy.

And yes, I'm just speculating on the difficulty of transitioning to 64-bit. If I'm mistaken, then I'm happy to be corrected. (But I'm fairly sure I'm not mistaken on at least some aspects.)

@Chain-Q
I see that I'm not the only one horrified by this idea :-/

Last edited by ChrisH on 28-Feb-2017 at 11:52 AM.
Last edited by ChrisH on 28-Feb-2017 at 11:47 AM.
Last edited by ChrisH on 28-Feb-2017 at 11:43 AM.
Last edited by ChrisH on 28-Feb-2017 at 11:42 AM.

_________________
Author of the PortablE programming language.
It is pitch black. You are likely to be eaten by a grue...

@ChrisH

you make a problem where no real is

there is X86 (32bit)
ARM (32bit, do not know of 64bit there)
68k (32bit)
and of course AMD64

I do not believe that the rest will be dropped so we will see what happens. BTW people are all the time asking for SMP, 64bit and MP on AmigaOS, except MP Aros will offer that. MorphOS team also announced ISA change and a part of that will be SMP and 64bit.

@OlafS25

i think chrish refers to his software (portable-e?) he currently provides across the systems (morphos, os4, aros x86 abi-v0). now if his software is 64bit safe (pointers being IPTR type instead ULONG and the like) it shouldnt be probably that much of a problem to compile it against abi-v1 headers and libs and have it available for 64bit platforms instead only 32bit ones, as it is currently the case.

but if he can not or doesnt want to support 64bit for some reason (no pun intended! there might be a valid one) then potential aros-x64 users will have to resign on it.

@ChrisH

Quote:

And from a cross-platform developer point of view, one of the reasons I still manage to support AROS (to some degree) is that AROS is basically source-code compatible with OS3.x (along with OS4 & MOS). I fear that changing AROS to 64-bits will make it almost impossible for me to support AROS

Huh? Changing AROS to 64bits? Please elaborate...

AROS is already 64bits along with 32bits, both compiled from the very same source code. AROS is also x86, ppc, arm and m68k, all compiled from the very same source code. Supporting AROS is just as easy as it was until now. Guess what, 10 years ago there was only small amount of changes necessary to make entire AROS source code base 64bit compatible. Yes, there are still here and there small bugs which were overseen, but change form 32 to 64bit is not a kind of rocket science or some other magic mystery.

Quote:

The change from ABIv0 to ABIv1 on it's own would have been bad enough,

That change affects more the binaries and not really the source code of user applications.

Quote:

I am doubting that changing to 64-bit will be anything like as easy.

The hardest part in making 64bit aros were low-level details which should interest only those who wrote them. The change to 64bit is easy. If you doubt, show me the code in question and I will show you how to do that :P

Btw. I just had a look at PortablE. Quoting your manual:
Quote:

Pointers are considered larger than QUAD (& LONG), but smaller than VALUE. Also a PTR will not accept a QUAD, but neither will a QUAD accept a PTR. In case it is not obvious, this means that VALUE can also store pointers, but LONG cannot.

it seems that you have written PortablE already with 64bit compatibility in mind.

Quote:

And yes, I'm just speculating on the difficulty of transitioning to 64-bit. If I'm mistaken, then I'm happy to be corrected.

Yes, you are mistaken. On AROS following rules apply:
1. BYTE/UBYTE is 8bit, WORD/UWORD is 16bit, LONG/ULONG is 32bit, QUAD/UQUAD is 64bit, the types are comparable with stdint types (int8_t, int16_t, int32_t, int64_t)
2. IPTR/SIPTR are integer types large enough to fit pointer, that is sizeof(IPTR) = sizeof(APTR) = 4 on 32bit system, and = 8 on 64bit system
3. ti_Data in TagList is large enough to hold a IPTR/APTR type.
4. never store a pointer in integer of type LONG. It may work (if the pointer has upper 32bits clear), but does not have to. Compiler should warn you about that.
5. If you are unsure about point 4, allocate your memory with MEMF_31BIT flag set. But don't expect that AROS internals will do the same.

the point 4 is actually important.

Last edited by michalsc on 28-Feb-2017 at 12:47 PM.

@michalsc

Quote:

Huh? Changing AROS to 64bits? Please elaborate...

i think he really means the most popular (so to say default) aros platform (currenlty x86 abi-v0) may soon shift to x64 (abi-v1?). i think thats how it may be perceived outside.

@ChrisH

Quote:

Oh dear. I thought people would have learnt by now (there are enough examples over the decades) that an attempt to force a transition to an incompatible "improvement" just results in many people not upgrading at all (and potentially driving them away to competitors), thus destroying whatever market share you had, particularly when there is zero apparent benefits to the end user. (I now expect lots of explanations about why 64-bit is soooo much better... Which will entirely miss the point.)

Users tied to operating systems which are unable to see and use more than 2 or 3 GB of RAM, maybe, having a larger address space can seem pointless, but I can absolutely assure you that the typical PC users, who generally have systems with 8 or even 16 GB of RAM and are currently bound to 32bit AROS' 4 GB limitation would be really glad to use also the remaining RAM on their systems.

Moreover, single core CPUs are now obsolete and even hard to find. Most of us have AROS installed on 2- or 4-core computers where the first one works, and the others just sit down looking at it. Having the ability to use the other cores - maybe even for specific tasks - would be a hell-more-than-apparent "benefit" for everyone of us.

I perfectly know that the transition won't be easy. I will struggle to bring Icaros 64 to the same level of current Icaros, because this and that won't be initially available. But the progress is something you can't stop just because people are accustomed to something.

MorphOS and AmigaOS never went to 64bit nor added SMP for the simple reason they would break compatibility with M68K (but this is still to demonstate... let's see how future 68K AROS will behave), and since 68K programs are still a sensible matter for their user, they simply can't do this move. Otherwise, they'd be forced to use the same UAE integration trick we've been already using for AROS. And, you know, once you have a 64bit UAE program that you can use... your old 68K programs still continue to work like they did on 32bit UAE. So nothing changes for AROS in this regard.

Quote:

And from a cross-platform developer point of view, one of the reasons I still manage to support AROS (to some degree) is that AROS is basically source-code compatible with OS3.x (along with OS4 & MOS). I fear that changing AROS to 64-bits will make it almost impossible for me to support AROS, while also simultaneously supporting OS4 & MOS, and so I will have to completely drop AROS. The change from ABIv0 to ABIv1 on it's own would have been bad enough, but "merely" a recompile for 99.99% of programs, and I guess that (for example) it wouldn't be too hard for AmiDevCpp to get updated to support it. I am doubting that changing to 64-bit will be anything like as easy.

I can't understand exactly where your problem exactly is. You should just start by recompiling PortablE executables to x64 and see what happens, keeping in mind what Michal Schulz told you. On AROS-EXEC and AROS mailing lists you can find tons of helpful hints, and some very skilled people can help you with the transition.

AROS itself can be compiled to different targets using the same sources, the same can be done to any program written with portability in mind (and, funnily, your product is called PORTABL-E, I'd be very surprised to discover it wasn't so portable after all...).

@thread

Quote:

paolone wrote: ... I can absolutely assure you that the typical PC users, who generally have systems with 8 or even 16 GB of RAM and are currently bound to 32bit AROS' 4 GB limitation would be really glad to use also the remaining RAM on their systems. ...

Full ACK!

Using 64Bit systems on PC could be considered as 'normal' today.

Maybe future AMD/Intel CPUs will neglect the support of the x386 mode, this mode will be available for the next 10 years (or more) but all optimisations will go into 64Bit modes. Staying 32Bit means to be stuck on a dying architecture.

Binary compatibility to x386 AROS will be almost impossible, AmigaOS is a system using shared structures, a 32Bit application can't access 64Bit system structures as long as it is not compiled to do so. Even a 32Bit API emulation for a 64Bit system will not help on this issue.

You can compare it with the problem of a seamless 68k emulation with full access to the structures of an x386 AmigaOS (endian incompatibility)

Last edited by OneTimer1 on 28-Feb-2017 at 09:51 PM.

@paolone

Quote:

I can't understand exactly where your problem exactly is. You should just start by recompiling PortablE executables to x64 and see what happens, keeping in mind what Michal Schulz told you. On AROS-EXEC and AROS mailing lists you can find tons of helpful hints, and some very skilled people can help you with the transition.

maybe even making one program 64bit aware may lead the path for os4 or morphos 64bit adopted versions, should that be doable and desirable at some point in the future.

@michalsc

https://www.youtube.com/watch?v=mCRlP6M-PVo&feature=youtu.be

:)

_________________
Support AROS sponsor a developer.

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

@terminills

what arre the programs that are causing the load on additional cores?