Official update to OS 3.1 from Hyperion

[wawa]

Originally Posted by matthey

There is Frank Wille's open source PosixLib which is more Amiga friendly than ixemul.libary.

same on aros i believe. at least there is posixc.library in libs, even though i dont know the extent of functions it delivers. ixemul works though as well on 68k thanks to toni fixing lddemon.

[wawa]

Originally Posted by matthey

Was it really necessary to rant all over wXR?

even though i sympathize with the open source idfea. i also think that there has been enough ranting on part of wxr, to justify a reply. and this was a reasonable kind of answer imho.

[Threader]

Originally Posted by matthey

I believe AROS already has an optional TLSF memory handler and that it is even the default option on some builds. I don't know if it as good and optimized as the 68k AmigaOS patch though. It would need to generate the BFFFO instructions to really be amazing, especially on the Apollo Core with its super fast bit field instructions (back when Gunnar was listening to me).

The problem with 68k AROS is that few Amiga users want to use it because it is less efficient than AmigaOS. Many Amiga users want features and optimizations without really knowing much about it. I am partially guilty myself.

Very interesting, I've not been in a position for a while to follow much, for the past few months I've been intrigued by the latest developments – gcc 6.2, sonnet ,etc. .. --I've been reading up.. Problem is, what I've now read raises too many red flags to sit back and shut up.. It’s certainly not progressive to scream shit at where you should progress...It appears like he is collecting information to counter the trademark...

This is not the time for hostilities, by calling that out i wish to advice, by his own words and your, he should be smart enough to have a clear focus, and not raise hell like this in a time where we could make a difference, i've had time to consider, maybe the stress is eating at his brains, the trolling got to me.

Maybe this will help… 50k right there, thank Megacz! ( Go figure, http://aminet.net/search?readme=megacz )
fscreen and - http://aminet.net/package/util/misc/gfxroute
Hacked headers for use with gcc http://aminet.net/package/dev/lib/hackyheaders
Speedy ide – Blizkick (<3 piru) http://eab.abime.net/showthread.php?p=591471&styleid=4
( Give a soul like Megacz 50k and be done with it, stop bitching about, progress aint easy, we got this far by coincidence, or distraction, we are at the crossroad where we might make it, start focusing your influence towards something realistic and positive, there are tonnes of issues needing attention
)

Originally Posted by matthey

Was it really necessary to rant all over wXR? The situation is frustrating so it is natural to want to shake things up. Several of the businesses involved have been arrogant, involved in shady activity and have done little to help the current situation while tightly clutching their precious until the end. The lower class peasants grow restless as they have been ignored. At least wXR has been trying to make something, anything happen.



I have considered it especially if things don't change with the Amiga. I would miss some Amiga software and the 68k though.

I would of course support an open source 3.1 , screaming death and blot will not solve anything.. I'll admit, it's rather ruthless of me, but i've read the posts...
He could have put your money his mouth is, he could have contracted Hyperion for 68k 4.1, supported Aros, anything but trying this shit..
Focus and think ffs, were at a new avenue, finafuckingly... Nuff said..

[Kalamatee]

Originally Posted by matthey

Allwinner is not even a market leader anymore as you are right about the competition. Almost all of the competition is ARM though. ARM has too many modes and variations for software which is close to the hardware (ARMv8 tries to standardize more but this now requires a very high spec) and lacks standardization for efficient pre-compiled executables. Android's byte code is not efficient compared to a 68k Amiga executable and the AmigaOS can be optimized for more standard hardware (new enhanced standards needed). Thumb 2 is a big trade off in performance for code density which is not necessary with the 68k which has double the GP registers and starts with better code density which can be further improved with a performance gain. The CISC 68k can also have better single core performance without OoO execution which should give good energy efficiency and saves logic. ARMv8's AArch64 is big and fat (logic, number of instructions, cache requirements) with most performance gains coming from auto-vectorization (possible with 68k SIMD unit but not Thumb 2) and die shrinks as ARM tries to hide what would normally be a performance loss in their zeal to push into the server market. Most embedded does not need 64 bit pointers with a CPU with good code density and smaller is faster. The Raspberry Pi 3 uses an energy efficient in line superscalar ARM Cortex-A53 but most OSs for it are not using AArch64. Some are starting to as Thumb 2 was handicapped in using the SIMD so no auto-vectorization but where this is not possible the code is just as likely to be slower (not uncommon for the original ARM32 code to be fastest too). We have a similar situation as the 64 bit Intel x86_64 being accepted because of the performance benefits of ISA improvements (doubling of GP registers being the best improvement), bigger caches and die shrinks which more than offset the 64 bit performance loss on average. I see all these inefficiencies, mistakes and doing things the difficult way and just think that a different way might be attractive and competitive. The Amiga community already has some of the work done to make it happen if the resources could be pooled and their was enough cooperation.

Which CPU choice is not the problem, the ability to run on which ever is the current "flavour of the week" with little effort is - something AROS wins hands down over all the other "AmigaOS" flavours.

There is Frank Wille's open source PosixLib which is more Amiga friendly than ixemul.libary.

http://aminet.net/package/dev/c/vbcc_PosixLib

The major problem is the header file incompatibilities and inconsistencies which are necessary to support the POSIX functions. GCC has not waited for and followed the POSIX standard strictly and compatibility with GCC is very important so its a mess to support. Support should have been added to compilers in modular libraries like Frank's PosixLib and my builtin library but GCC has the big fat bloated compiler philosophy.

That's not entirely true - or hasn't been as bad for the past few major versions. The main issues is the lack of effort to provide proper "amigaos" shared versions of the used modules, resulting in bloated statically linked binaries.

I believe AROS already has an optional TLSF memory handler and that it is even the default option on some builds. I don't know if it as good and optimized as the 68k AmigaOS patch though. It would need to generate the BFFFO instructions to really be amazing, especially on the Apollo Core with its super fast bit field instructions (back when Gunnar was listening to me).

AROS has had TLSF for some time now, and has used it as the default memory allocator on most platforms for the whole time, so it has been pretty well tested.

The problem with 68k AROS is that few Amiga users want to use it because it is less efficient than AmigaOS. Many Amiga users want features and optimizations without really knowing much about it. I am partially guilty myself.

That is the problem for m68k users for sure. And because of it, the m68k branch doesn't get the love they would want it to get - a bit of a catch 22.

Though, the situation is somewhat true also on the platforms it has supported since day one. The people who do use AROS are generally content with the performance since they use more powerful hardware and don't perceive some of the performance issues - and certainly don't benchmark/profile code to identify things that could be improved, less so look at ways to improve it.

Understandably, the limited number of devs are also held up more with getting the code/ecosystem working across different platforms in the first place which is a considerable task/feat considering the amount of hardware/build environments it works on and with.

Several of the businesses involved have been arrogant, involved in shady activity and have done little to help the current situation while tightly clutching their precious until the end.

Sadly that is a conclusion I came to almost 20 years ago now, and nothing has changed - its even the same people that are still trying to pull the reigns of the projects they have acquired. I try not to even get involved/follow much that happens in the AmigaOS world because of the childish drama the user base seems to thrive on, and the divisive way in which the companies still operate (Hyperions 3.1 update being a prime example).

Its saddens me though to see so many people supposedly want to see an open source "AmigaOS", yet unwilling to help/plain obstructing AROS. If some of them spent half the effort actually contributing that they did whining/contemplating/speculating on forums, it would have been a non issue long ago.

[Kalamatee]

Originally Posted by wawa

given some work put into this, along with perhaps porting some amiga feats from bebbos gcc6 to aros toolchain, things might improve.

This always smells like a red herring to me. Create a non-issue and circularly use it as an excuse to not ever really "support" a toolchain.

We have no problems producing suitable binaries for m68k, though we use a separate tool to convert elfs to hunks - but who cares if your only goal is to produce a working binary? Why keep dragging out/creating a need for patches that don't get accepted upstream if you can work around it?

[Samurai_Crow]

Originally Posted by Kalamatee

This always smells like a red herring to me. Create a non-issue and circularly use it as an excuse to not ever really "support" a toolchain.

We have no problems producing suitable binaries for m68k, though we use a separate tool to convert elfs to hunks - but who cares if your only goal is to produce a working binary? Why keep dragging out/creating a need for patches that don't get accepted upstream if you can work around it?

I think bebbo has gone beyond making a toolchain for hunk executables to adding optimization passes for more effective code generation.

[alpine9000]

Originally Posted by Samurai_Crow

I think bebbo has gone beyond making a toolchain for hunk executables to adding optimization passes for more effective code generation.

This is true.

Also bebbo's work brings back the "amiga" features that the vanilla m68k gcc lacks.

I am not sure how you go about doing things like chip ram sections, register parameters etc with the base gcc, I'm sure it's possible, but with bebbo's port you can do it the same way as the gcc versions that supported Amiga.

[wawa]

Originally Posted by Kalamatee

Why keep dragging out/creating a need for patches that don't get accepted upstream if you can work around it?

for what i know the same is the issue with aros patches, they cant be pushed upstream, unfortunatelly. im am all for reducing the extent of patches necessary in order to be able to keep up with upstream and i know that we can generate 68k binaries fine, which has mostly been tested with 68000 code for now, but as its been mentioned above bebbos branch seems to contain fixes that _might_ be useful for us on aros m68k backend. i am not trying to force it through, as i dont know anything about it, rather i support my opinion mostly on tonis complaints about 68k code generation on aros.

it has been for instance repeatedly brought up that aros binaries are usually bigger than corresponding genuine amiga ones. which is imho not alway true and the difference is around 15%, like maybe 60kb instead of 50. which might well be due to optimization and plain 68000 compile, i dont know.

[Kalamatee]

Originally Posted by wawa

for what i know the same is the issue with aros patches, they cant be pushed upstream, unfortunatelly.

No, it is not. We haven't persued pushing them (the 6.x patches) yet since they are considered experimental but at some point we will be cleaning them up and attempting to do that.

im am all for reducing the extent of patches necessary in order to be able to keep up with upstream and i know that we can generate 68k binaries fine, which has mostly been tested with 68000 code for now, but as its been mentioned above bebbos branch seems to contain fixes that _might_ be useful for us on aros m68k backend. i am not trying to force it through, as i dont know anything about it, rather i support my opinion mostly on tonis complaints about 68k code generation on aros.

Which complaints? Its is often better to base your opinion on testable facts, than someone elses opinion/what you read on a forum regardless of who they are.

it has been for instance repeatedly brought up that aros binaries are usually bigger than corresponding genuine amiga ones. which is imho not alway true and the difference is around 15%, like maybe 60kb instead of 50. which might well be due to optimization and plain 68000 compile, i dont know.

And you know for a fact its because of the compiler produced code, and has nothing to do with what is being linked in, the flags being used/badly written code? Simply unrolling loops (a common optimization which improves performance depending on the loop..) can account for such a difference, or the jump from the 4.x to 6.x toolchain.

You do know AROS also doesn't even strip all unneeded symbols from the binaries?

[Toni Wilen]

When I can compile aros with "fixed" gcc (without too much pain!), I'll check if code looks better

Use of built-in register parameter support should also improve generated code quality (vs current really ugly inline assembly hacks..), assuming it enables optimizer to work more optimally.

(Isn't this quite off topic discussion?)

[Kalamatee]

Originally Posted by alpine9000

This is true.

Also bebbo's work brings back the "amiga" features that the vanilla m68k gcc lacks.

I am not sure how you go about doing things like chip ram sections, register parameters etc with the base gcc, I'm sure it's possible,

The same way as every other GCC using platform, and the same way we also have to for Clang, or other toolchains.

but with bebbo's port you can do it the same way as the gcc versions that supported Amiga.

Please - no one liked, and seldom used, gcc when that was the case.

[Kalamatee]

Originally Posted by Toni Wilen

When I can compile aros with "fixed" gcc (without too much pain!), I'll check if code looks better

Thanks Toni.

Use of built-in register parameter support should also improve generated code quality (vs current really ugly inline assembly hacks..), assuming it enables optimizer to work more optimally.

Well, you should never assume

But I digress, there's no guarantee of what you claim at all "unless" you know exactly what code is going to be generated in the first place.

My experience (and understanding from discussions on the mailing lists for GCC etc) is that it in fact has the opposite effect in a lot of cases due to forcing the compiler to work with specific registers/not letting it choose/reorder them, especially once the code is optimized.

(Isn't this quite off topic discussion?)

Yeah seems to be ;D

[wawa]

Originally Posted by Kalamatee

Which complaints?

there you go, i have heard it repeatedly from toni that it doesnt make sense to invest more work in aros until 68k code generation has been improved, compilers not being his field though. therefore i considered bebbos work as opportunity to finally take look at and solve this issue, given it actually needs to be solved.

in fact many expectations occur to be prejudices. i remember thread where deadwood and phx tested vasm in order to check if vbcc suite would provide better coder generation for 68k than gcc as many expect. it was proven wrong.

i think this is very right to talk this through between informed parties, no matter offtopic or not, open sourcing of amiga os isnt gonna happen anyway. but we can open a separate thread if need be.

[wawa]

btw, it looks like they just finally managed to get aros booting on apollo, quite some uproar there:
http://www.apollo-core.com/knowledge.php?b=1¬e=5580

http://amigaworld.net/modules/newbb/...41815&forum=27

[Kalamatee]

Originally Posted by wawa

there you go, i have heard it repeatedly from toni that it doesnt make sense to invest more work in aros until 68k code generation has been improved, compilers not being his field though. therefore i considered bebbos work as opportunity to finally take look at and solve this issue, given it actually needs to be solved.

Sorry - I still don't see anything tangible actually being claimed, or anything
identified as needing "fixed". So claiming there is some issue needing solved/fixed is unfounded.

in fact many expectations occur to be prejudices. i remember thread where deadwood and phx tested vasm in order to check if vbcc suite would provide better coder generation for 68k than gcc as many expect. it was proven wrong.

My point exactly - and my problem with a lot of the "claims", that ultimately prove to be just someone's prejudiced view and unsubstantiated, often hurting AmigaOS in the process.

i think this is very right to talk this through between informed parties, no matter offtopic or not, open sourcing of amiga os isnt gonna happen anyway. but we can open a separate thread if need be.

[Kalamatee]

Originally Posted by Samurai_Crow

I think bebbo has gone beyond making a toolchain for hunk executables to adding optimization passes for more effective code generation.

That's great - and probably why it wouldn't get accepted as such. Changes to how GCC actually works are the main problem and something we try to avoid/let people who work on GCC itself deal with. The path of least resistance works better for us

Also - my comments are certainly not meant to be any kind of disrespect to bebbo or what he has achieved, but trying to add too much to the toolchain is always going to be a downfall in getting it accepted.

p.s. - most of the mentioned things have nothing to do with gcc and are handled by binutils (ld, etc).

[Samurai_Crow]

68k has needed an updated backend for a long time. I don't care if it gets upstreamed as long as it does the job.

[Kalamatee]

Originally Posted by wawa

btw, it looks like they just finally managed to get aros booting on apollo, quite some uproar there:
http://www.apollo-core.com/knowledge.php?b=1¬e=5580

http://amigaworld.net/modules/newbb/...41815&forum=27

Maybe it will help improve the situation for m68k users

Its good to see that they have got it up and running with relatively little effort.

[wawa]

Originally Posted by Kalamatee

Maybe it will help improve the situation for m68k users

Its good to see that they have got it up and running with relatively little effort.

it is one of the prejudicies that aros is hard to install, the other that it cant be made usable. ive had to do with this all the time.

[wXR]

@wawa

I am amazed and really proud of you guys. So what's next? Thrasher has a good idea there, let's start a thread about AROS improvements that we can help along with a bit of bounty money, time, and elbow grease. I'd love to see this momentum leveraged to the fullest extent.