AROS World Exec
Development => Development (General) => Topic started by: HenryCase on February 18, 2019, 03:51:30 PM
-
Hi,
I was just wondering if there was any news on the native ABI V1 version of AROS for x86/x64 hardware?
I see that the main distros are sticking to ABI V0 for now, and I wonder whether there's due to be a transition to ABI V1 soon, and what it would take for that transition to start?
Also, if there's anything that users can do to speed this along, I'd be interested in hearing what would help the most with this transition.
-
I am curios too.
-
Not much is happening. Aros development is almost only happening with the arm port. It is our last chance the way I see it. At least we have a stable and good abi v.0 version for i386 that is fun to play with. 68k aros is abi v.1 and is also little interesting. Vampire etc.
-
Not much is happening. Aros development is almost only happening with the arm port. It is our last chance the way I see it. At least we have a stable and good abi v.0 version for i386 that is fun to play with. 68k aros is abi v.1 and is also little interesting. Vampire etc.
There's been plenty happening. Build system updates, Application fixes, Subsystem fixes/enhancements. Just because you don't see it doesn't mean it's not happening.
-
Yes there's activity, and there has been activity for years. But in terms of the original question, an updated gcc won't make the transition happen anytime soon. There's also libs and drivers that need to be done, not to mention the ABI itself.
In the mean time, perhaps we should focus on other things, radeon drivers? sata handlers? python? etc, etc, etc.
-
To be honest, I simply would declare the AB! v1 project done.
I would dump 32bit x86 completely, nobody needs this anymore and declare v1/64bit x86 as completed. There might be issues left (most likely there are), but if really necessary, those should be fixed in ABI v2..
ARM/m68k are v1 anyways already..
-
Is there any (updated) document which reports the ABI v1 status?
-
Yes there's activity, and there has been activity for years. But in terms of the original question, an updated gcc won't make the transition happen anytime soon. There's also libs and drivers that need to be done, not to mention the ABI itself.
In the mean time, perhaps we should focus on other things, radeon drivers? sata handlers? python? etc, etc, etc.
Saying there's no almost no activity is 100% wrong. Which is my point. However an updated development environment does help speed up the transition as it helps find bugs.
-
Staf was the driving force behind ABI V1. He set some extremly ambicious goals for ABI V1 but was just one person. Somewhere around 30% of the way he lost energy to continue. This has been the state from circa 2014/2015. In this light I think calling ABI V1 done is not correct.
What I would suggest to remaining active developers is to vote on communicating that ABI V1 effort is stopped and that X86_64 will from now on maintain source and binary compatibility.
-
currently the driving force behind abi v1 development is still nick. michal is the second most active contributor, even if mostly in arm be target area.
i think its for those two people and neil to tell how this is to be handled. anyhow nick is actively setting up the tasks to complete for abi v1 and him and michal are constantly discussing that stuff on slack. there is also a number of other aros developers, contributors and sympathisants providing now and then valuable feedback and offering their ressources, like marlon, who has set up a build server for aros m68k tailored distribution.
so things are not that bad, just because the developers may not be posting here all the time. as i always say, yoiu may simply follow the commit logs to aros svn repository to see what progress there is.
-
@deadwood
btw, as i already said it might bve beneficial if yo joined us, if not as contributor, then in an advisary role. and i measn not especially aros but looks like we have another contributor from os4 camp (jaokim) to work on common odyssey source. since you have experience with it, there might be issues probably of all accesible people only you could answer. kas1e is also there but mostly busy with os4 sdl, ao there aint that much interaction.
-
Staf was the driving force behind ABI V1. He set some extremly ambicious goals for ABI V1 but was just one person. Somewhere around 30% of the way he lost energy to continue. This has been the state from circa 2014/2015. In this light I think calling ABI V1 done is not correct.
What I would suggest to remaining active developers is to vote on communicating that ABI V1 effort is stopped and that X86_64 will from now on maintain source and binary compatibility.
That is what I meant. Of course not all original v1 goals have been reached, so you are right. In the end the difference is just how you name it, the fact remains the same, a stable x86_64 with current features.
But I am not the one to decide here.
-
but what would improve if we called the current state a finalized abi v1?
-
ABI v2 implies a compatibility breaking feature list. We can expand upon certain library features without breaking compatibility with the older ones for an ABI v1.1 or something.
-
Tbh what i read being outlined by nick is within reach. Among others i think thw source compatibility needs to be confirmed.
-
@wawa
'within reach' is an interesting phrase in answer to the original poster. It could mean 2 more weeks, 2 more months, or two more years.
Btw I'm curious, If I may ask, Why are you making commits for Kalamatee?
-
within reach in terms of features to be implemented, how long it finally takes depends on te rate of development which is currently not that bad considering obstacles.
i dont know why kalamatee cant or wont reactivate his svn access, he is apparently technically restricted in some ways as of current. so ive taken this over since a while.
-
btw within reach means exactly what it means, within reach, it may stay remote forever though;)
-
Nick's goal is for ABI-v1 to be "complete" by the end of the year, and 2019-2020 be the year of ABI-v1 and start phasing out ABI-v0 completely, which is preferred sooner rather than later.
-
I tried the i386 version, on a toshiba satellite and everything works, on my fujitsu I express no