Which 68060.library?

[wawrzon]

in case there is anyone interested to check, perhaps there is any room to improve aros 680x0.library inparallel. sorry to sound like broken record but thanks to mattheys hint on the other thread a huuuge lag in aros graphics.library could be identified, hopefully to be fixed soon.

[wawrzon]

On a related note, does PeterK's icon.library work on AROS 68k?

yes. and its quite a boost. ill try to roughly profile aros icon.lib against it next, after the bltbitmap issue is outta the way. perhaps it gives some results about critical parts, if need be to solve by asm inlines.

Hopefully over time we can all contribute a bit here and there in different areas depending on expertise and make AROS a fit successor to 3.x.

thats my hope, a fully open extended amiga os.

[wawrzon]

I wasn't working on the 680x0.library when I found the bug. I was testing the results of some vbcc C99 math functions against the trapped FPU 68881/68882 instructions. I'm amazed at how many major bugs I've found lately in software that has been out for so long of time. I think a good 68k compiler is an important key to AROS 68k's success. I know vbbc doesn't currently produce AROS code but I expect that will change when it gets good enough. With all the 3D programming and porting you've done, would you appreciate a compiler that has better C99 math support than GCC 3.4.0? You want to try it out?

alas its till not within reach, and even if i had any influence upon that there are technical issues in its way. it has been discussed again and again. i fear we have to live with it for now except someone will suddenly emerge who will take care of it.

[wawrzon]

The early GCC 4.x versions generated poor 68k code. Supposedly the newest versions of GCC are better.

i once have benchmarked the same machine with aibb under aros and genuine kickstart for comparison and the results in most areas were the same. how would that be if gcc4.6.2 (this is the currently used version i guess) was so bad overall?

my impression is that you cant blame the compiler for aros performance flaws. its design decisions, missing, not efficient or simply wrong code, all that to be found and fought one by one.

[wawrzon]

The newest versions of GCC 4 have improved the 68k code generation and fixed bugs. It's as good as most of the old 68k compilers now.

its my impression, but im not an expert;) like you.

it doesn't schedule instructions for the 68060, it uses bitfield instructions way to much for the 68060 (shift+mask is usually faster in registers) and the FPU support is worse than earlier versions of GCC but probably not used much by AROS.

aros is not compiled with 68060 target, im not sure what target it actually is but i guess widest common denominator, either 020 or even 000. however the fpu effectivity is wort to check, thanks for reminder.

Piotr tried compiling ffmpeg without bitfields and it didn't make much difference so I would expect some of these large complex programs are cache/memory bound on the 68060. We saw the same with NovaCoder's AmiQuake 2 where some of the assembler optimizations I did didn't make much different. Optimizations can still help but not nearly as much.

toni calls it micro optimisations. probably this should really wait, but peter k's icon lib proves worthy to take care of it already where its due.

All my Amiga code is free with sources available. The AROS devs have my code and I expect some of it has been integrated in some form. If we can't revive the Amiga then it's not going to do anyone any good.

certainly, your code patches for mem copy are applied by aros setpatch depending on what cpu be detected. thats all how cpu bound optimisations are currently haldled on aros, as patches for the sensible functions, and i think its a good way. jason have introduced these inlines (?) you are probably mentioned in the sources.

[wawrzon]

@ThoR

hi! have you ever planned opensourcing your MMU.library & tools? I guess it could be a great addition to AROS and would probably bring some new life to our classics :-) Maybe somebody like Matthey could add some improvements, who knows.

most what i ever needed thors 060 and mmu libraries was his muforce. now, aros (68k) has already both 060 library functionality (within the 680x0.library, based on the same open sources all other 060 libs are based on) and enforcer functionality to be turned on/off at boot time. that said having thor as consultant on above matters (and more) would certainly be quite a gain for aros team. but i doubt he has enough time and interest, especially his doubt afair was always if aros can become compatible enough.

[wawrzon]

+1 to ThoR's stuff being in AROS.

Wawrzon mentioned that Matt's ultra-fast 060 CopyMem routines are already in the AROS m68k Setpatch.

thor has always mentioned that he doesnt particularly like to open stuff to just everybody, in order to avoid it to be messed up by incompetence. i have talked to him about aros once in private (thomas, you remember?) so i guess if he wanted to particularly support aros he would do already. i for my part dont want to make demands of anybody, accept and understand the standpoint.

[wawrzon]

With PeterK's icon.library, Matt Hey's CopyMem routines, ThoR's stuff, Mathias Henze's HSMathLibs and Oliver Robert's WarpDT datatypes, AROS m68k would be much better than it is now.

It's a shame the dos.library/scsi.device/graphics.library stuff on EAB can't be used as they are Resourced from the copyrighted CBM versions.

im not sure if peter.k icon lib wasnt resourced as well, only that the complete code has been replaced. now i dont know what the situation legally is. however as the work was not based on any sources, only on reverse engineering of binary and since the current library does not contain copyrighted code its okay i guess.

its possible to use this library anyway and it gives nice speedup.

what concerns math libs i have never been sure how much do they improve upon genuine ones. at least integer wise aros is currently on the same level as aos afair. have to check for fp.

as for warp datatypes these are commercial, you can surely use them under aros 68k as you do on aos, no doubt, you just need to buy them.

all in all there are few aspects aros has serious performance problem. one of them has just been traced doen to a particular function within graphics library, seems toni has problems to improve it though. i will try to make it more public on the dev list.

[wawrzon]

Time to clone the drive to a WinUAE setup now that it has 68060 and MMU emulation?

it is (up to?) 040 mmu emulation.

[wawrzon]

I would prefer a different model here as I see a lot of needless branches and "headless" discussion going on in the open source world. That does not mean that I don't want to provide sources, but it means that I would prefer someone to feel responsible and "wear the hat" as we say here.

i know your opinion on this, but im sure if you actually was interested, you would find a quite reasonable team behind aros. their opinions may vary but usually they are following some con-sens very close to that what a regular amiga user like me actually recognizes as "improved amiga". the platform branches are a handicap on one hand because there is no focus on particular platform but a gain on the other hand, because of cross testing and remaining future proof in a fast evolving it world. the problem is of course there is no lead, so everyone just works on what he is just interested in, and there is no way to impose anything on anyone, but this is effectively the same how it is on each and every amiga related project today (mos or os4), even if it isnt openly admitted. all in all if you handed over your sources to jason or toni im quite sure they would be treated properly, but its your choice and i don want to talk you into anything.

[wawrzon]

Well, let me ask what the benefit of this would be. For emulation, the 68060.library is really pointless. For real hardware, it is (still) in supported mode, though probably with longer turn-around times, so I have no problem with it at all when people use it with AROS - or ship it with part of AROS. This is perfectly fine. The only thing I'm asking for is if you sell(!) a CD, please send me a copy, which is - I hope - not asking for too much. (At least, I have now two Amiga Forever DVDs. (-;)

Arguably, it might be anoying that it took so long to actually look into this bug and fix it. In the old days, I had turn-around times of probably one day, now it's more one month. But it also took years to actually discover it... Feature requests and bug reports are still read, though it takes time to implement and verify. Given that I hear nothing, the interest must be really low, or things must really work well. I don't know which of the two is true,  probably more the former than the latter.  

So I guess, it really boils down to one question, and that is: What would be better under a different model, and what would it enable?

what concerns different model, i see aros as a sort of code preservation repository, where all the good parts can be stored and eventually maintained beyond the point, where they would have been discontinued by their creators otherwise. that doesnt mean that anyone can be forced to contribute, but i dont believe anything worthwhile can be done on widest understood amiga platform today by a single person, let alone anything commercial can be pulled. sure, im certain you can maintain what you have developed for another few years. i dont ask you to contribute your code to aros. aros has already 680x0.library that includes 68060.library implementation. all i could imagine to ask to review the code if need be and consult the developers not to let them run into the bugs you are aware of.