Which 68060.library?

[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.

[nicholas]

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.


thats my hope, a fully open extended amiga os.

Yeah, what OS4/MorphOS should have been.

I think you already know about the 68k assembly dos.library/scsi.device/graphics.library etc replacements on EAB.

It would be great if these things could be merged into the AROS 68k source tree if possible, obviously where it makes sense to do so for performance and compatibility reasons.

[nicholas]

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 leave with it for now except someone will suddenly emerge who will take care of it.

I spent the best part of two days modifying a small tool I wrote in C for MorphOS with GCC4 to also compile without complaint with VBCC for MorphOS, VBCC for 68k and SAS/C 6.58 for 68k.

It was a very labourious (though actually quite interesting) excercise so I can't even begin to imagine the mammoth size task it would take to modify the source tree of an entire operating system to compile with something other than GCC!

[matthey]

I spent the best part of two days modifying a small tool I wrote in C for MorphOS with GCC4 to also compile without complaint with VBCC for MorphOS, VBCC for 68k and SAS/C 6.58 for 68k.

It was a very laborious (though actually quite interesting) exercise so I can't even begin to imagine the mammoth size task it would take to modify the source tree of an entire operating system to compile with something other than GCC!

AROS was suppose to avoid the GCC-isms but it's not the easiest thing to do. My understanding is that there are only a few but that they are heavily used and difficult to avoid. The new version of vbcc will have improved C99 support and many bug fixes which should help compatibility with GCC. AROS vbbc support will take some sitting down by the brains behind AROS with Frank Wille to come up with some solutions. Vbbc has some advantages over GCC that I think will become more apparent soon. It is more portable because it's small and has less compiler dependencies. I can compile vbbc with vbbc on my 68060 Amiga in a couple of hours. I can't imagine doing that with GCC. The other advantage is that it doesn't use double memory indirect addressing modes. There are some 68k fpga processors being created that would prefer to drop these addressing modes (with a new 68k ISA hopefully). Vbbc (and vasm) will need less modifications and be easier to add support for these new enhanced 68k fpga processors.

[nicholas]

AROS was suppose to avoid the GCC-isms but it's not the easiest thing to do. My understanding is that there are only a few but that they are heavily used and difficult to avoid. The new version of vbcc will have improved C99 support and many bug fixes which should help compatibility with GCC. AROS vbbc support will take some sitting down by the brains behind AROS with Frank Wille to come up with some solutions. Vbbc has some advantages over GCC that I think will become more apparent soon. It is more portable because it's small and has less compiler dependencies. I can compile vbbc with vbbc on my 68060 Amiga in a couple of hours. I can't imagine doing that with GCC. The other advantage is that it doesn't use double memory indirect addressing modes. There are some 68k fpga processors being created that would prefer to drop these addressing modes (with a new 68k ISA hopefully). Vbbc (and vasm) will need less modifications and be easier to add support for these new enhanced 68k fpga processors.

I really like vbcc, it's very fast at compiling and produces well performing binaries on both 68k Amigas and MorphOS. It has a lot of potential and Frank really looks/sounds like he knows what he is doing and seems very passionate about his work which shows quite clearly in the end product.

For 68k code, which would you say currently creates the best performing binaries; SAS/C, GCC2, GCC3, GCC4 or VBCC?

In particular which produces binaries that perform best on an 060. Any particular recommended compiler switches?

One thing I like about GCC from v4.2 upwards is "-march=native" which detects the host machine's capabilities and automatically switches on the best flags for it. Combined with -O2 it creates very well performing binaries.

I don't know if vbcc has something similar?

/Sorry for derailing the thread everyone.

[matthey]

I really like vbcc, it's very fast at compiling and produces well performing binaries on both 68k Amigas and MorphOS. It has a lot of potential and Frank really looks/sounds like he knows what he is doing and seems very passionate about his work which shows quite clearly in the end product.

Frank is amazing! He deserves an award for his Amiga support. The nice thing is that he is not biased and supports everything Amiga. You get the best tech support in the world with Frank and it's free. He's a pretty good programmer too .

For 68k code, which would you say currently creates the best performing binaries; SAS/C, GCC2, GCC3, GCC4 or VBCC?

I think the unofficial Amiga version of GCC 2.95.3 is the best for most code. It's not the most advanced with optimizations or features but it generates consistently better than average code with few bugs. The unofficial Amiga version of GCC 3.4.0 is more advance and sometimes faster but it has a few bugs, some of which affect optimization. It's code quality can vary a lot but is generally average overall. Vbcc code quality is about on par with GCC 3.4.0 but can vary a lot also. It does some very advanced optimizations but then other generated code is obviously poor (but usually still works). Vbbc does use Frank's vasm which is the ultimate peephole optimizing assembler. It helps a lot and would benefit the other compilers if used. SAS/C is an old mature compiler. It's not advanced but the basic code generation is solid with few bugs. Some of the library link code is not the best for new processors like the 68060. Most of the classic AmigaOS is written with SAS/C so it can't be too bad but it's still pretty average code generation quality IMO. The early GCC 4.x versions generated poor 68k code. Supposedly the newest versions of GCC are better.

In particular which produces binaries that perform best on an 060. Any particular recommended compiler switches?

That's a tough call. No compiler really does much to optimize for the 68060. A good instruction scheduler would do wonders for the 68060, especially with mixed integer and FPU code. Frank mentioned something about Volker adding an instruction scheduler but I wouldn't expect anything soon. I did improve the 68060 integer 64x64=64 vclib code which is about twice as fast as GCC 3.4.0. Vbcc will be getting a m060.lib for the FPU that I have been working on and some more optimal and bug fixed FPU code in the backend, but the direct FPU support is still pretty raw. It will take some time to iron out bugs. Vasm optimizes double and extended precision fp immediates down if possible. This saves a lot of code and a few cycles. GCC still doesn't do this. GCC FPU generated code since 2.95.3 has been ok with less bugs than vbbc. The older versions of GCC use trapped instructions and don't support the 68060 as well. Some of the GCC 3.4.0 FPU code is slow as it uses the IEEE math libraries too much. The 68040 received pretty good support in GCC unlike the 68060, probably due to the 68k Macintosh.

One thing I like about GCC from v4.2 upwards is "-march=native" which detects the host machine's capabilities and automatically switches on the best flags for it. Combined with -O2 it creates very well performing binaries.

I don't know if vbcc has something similar?

No. Vbbc doesn't have anything like "-march=native" although it wouldn't be that difficult to add an option that looks at the Amiga SysBase->AttnFlags (I added an option like that in my version of the ADis disassembler). It also doesn't have any options for selecting a range of processors. However, using "-cpu=68060 -fpu=68060" and linking with the new "-lm060" should generate code that is optimized for the 68060 but works well on the 68020-68060 CPU and 68881-68060 FPU. Most 68040 programmers will want to link with "-lm060" or "-lmieee" instead of "-lm040" due to the greatly reduced precision of some functions on the 68040 because of the lack of FINT/FINTRZ (huge design mistake). My plan for the "-lm040" library is to provide high speed low precision functions without trapping. The current m040.lib is a combination of low precision and trapped FINT/FINTRZ. I've just made it more consistent. Vbbc generates much better quality code already with "-O1". It's usually an improvement to use "-O2" but not always. "-O3" didn't do much on the 68k in my experience. Some of the higher level optimizations are still not implemented for the 68k. The new version of vbbc will generate SAS/C style debugging info with the "-g" option on the 68k Amiga. This allows source level debugging with powerful gui debuggers like BDebug (Barfly) and CPR (SAS/C).

[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.

[_ThEcRoW]

So, for WinUae, what is the reccommended library when emulating the 060?.

[nicholas]

Frank is amazing! He deserves an award for his Amiga support. The nice thing is that he is not biased and supports everything Amiga. You get the best tech support in the world with Frank and it's free. He's a pretty good programmer too .

Yeah he's one of the Rock Star Coders of the Amiga scene for sure!

I think the unofficial Amiga version of GCC 2.95.3 is the best for most code. It's not the most advanced with optimizations or features but it generates consistently better than average code with few bugs. The unofficial Amiga version of GCC 3.4.0 is more advance and sometimes faster but it has a few bugs, some of which affect optimization. It's code quality can vary a lot but is generally average overall. Vbcc code quality is about on par with GCC 3.4.0 but can vary a lot also. It does some very advanced optimizations but then other generated code is obviously poor (but usually still works). Vbbc does use Frank's vasm which is the ultimate peephole optimizing assembler. It helps a lot and would benefit the other compilers if used. SAS/C is an old mature compiler. It's not advanced but the basic code generation is solid with few bugs. Some of the library link code is not the best for new processors like the 68060. Most of the classic AmigaOS is written with SAS/C so it can't be too bad but it's still pretty average code generation quality IMO. The early GCC 4.x versions generated poor 68k code. Supposedly the newest versions of GCC are better.

Thanks for the info, very useful.  Regarding the Amiga OS, what about 3.5 and 3.9?  Do you know whether H&P used their own atrocious StormC 3 compiler or GCC/StormC 4 or even SAS/C?

That's a tough call. No compiler really does much to optimize for the 68060. A good instruction scheduler would do wonders for the 68060, especially with mixed integer and FPU code. Frank mentioned something about Volker adding an instruction scheduler but I wouldn't expect anything soon. I did improve the 68060 integer 64x64=64 vclib code which is about twice as fast as GCC 3.4.0. Vbcc will be getting a m060.lib for the FPU that I have been working on and some more optimal and bug fixed FPU code in the backend, but the direct FPU support is still pretty raw. It will take some time to iron out bugs. Vasm optimizes double and extended precision fp immediates down if possible. This saves a lot of code and a few cycles. GCC still doesn't do this. GCC FPU generated code since 2.95.3 has been ok with less bugs than vbbc. The older versions of GCC use trapped instructions and don't support the 68060 as well. Some of the GCC 3.4.0 FPU code is slow as it uses the IEEE math libraries too much. The 68040 received pretty good support in GCC unlike the 68060, probably due to the 68k Macintosh.

I'm hoping that the recently ressurected 68k branch of Debian will lead to better 060 code generation from GCC4.

No. Vbbc doesn't have anything like "-march=native" although it wouldn't be that difficult to add an option that looks at the Amiga SysBase->AttnFlags (I added an option like that in my version of the ADis disassembler). It also doesn't have any options for selecting a range of processors. However, using "-cpu=68060 -fpu=68060" and linking with the new "-lm060" should generate code that is optimized for the 68060 but works well on the 68020-68060 CPU and 68881-68060 FPU. Most 68040 programmers will want to link with "-lm060" or "-lmieee" instead of "-lm040" due to the greatly reduced precision of some functions on the 68040 because of the lack of FINT/FINTRZ (huge design mistake). My plan for the "-lm040" library is to provide high speed low precision functions without trapping. The current m040.lib is a combination of low precision and trapped FINT/FINTRZ. I've just made it more consistent. Vbbc generates much better quality code already with "-O1". It's usually an improvement to use "-O2" but not always. "-O3" didn't do much on the 68k in my experience. Some of the higher level optimizations are still not implemented for the 68k. The new version of vbbc will generate SAS/C style debugging info with the "-g" option on the 68k Amiga. This allows source level debugging with powerful gui debuggers like BDebug (Barfly) and CPR (SAS/C).

That would be very handy, I've not really had any experience with Ralph's Barfly or it's GUI debugger but I do like the SAS/C debugger as it "just works".  Well, most of the time anyway. lol

Thanks again for the info, it's always an educational experience for me when you answer any questions I have about Amiga stuff.

Slightly OT question, but would your CopyMem routines be a good fit to merge into the 68k AROS source?  I imagine they'd speed it up a great deal.

I asked Matthias Henze who wrote the HSMathLibs if he'd consider donating the source for his libs to the AROS team because he doesn't get many registrations these days (Though I tell everyone I can to buy them) but he didn't reply to that specific question so I took it as a no.

It's a shame, as there are quite a few performance patches for 68k machines that if the source were donated to AROS could be included in the OS by default and make 68k AROS a much better experience than it currently is.

The WarpDT datatypes come to mind as a random example.

[nicholas]

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.

Well you can't blame the compiler for design flaws within AROS but a better optimizing compiler is always a good thing to have/wish for.

[bbond007]

No 68060.library.
I just run dual 68030 libraries ...

[nicholas]

No 68060.library.
I just run dual 68030 libraries ...

Yeah, from what I understand it doesn't really emulate an 060 it just shows  the CPU to the emulated Amiga as an 060 but the missing instructions from the previous CPU models are still there so the 060 libs aren't needed.

[matthey]

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.

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. Some of those new fancy optimizations work on the Amiga. However, judging by the only new GCC compiler code I've looked at (ffmpeg), 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. The new version of vbbc should have no problems beating the FPU code quality when it's debugged. 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. Shrinking the code enough with optimizations so it fits in the Icache might fix the problem but that is not possible with some large complex programs and the small (compared to modern processors) 68060 caches. The 68060 may run out of Dcache processing some data also.

So, for WinUae, what is the recommended library when emulating the 060?.

I believe it's generally best to emulate a 68040 and not the 68060. If you do emulate a 68060, ThoR's Mu 68060.library does try to detect the processor correctly. There was an old thread over on EAB where someone successfully used the Mu 68060.library with 68060 emulation while most alternatives did not work. Personally, I don't have much experience with WinUAE.

Thanks for the info, very useful.  Regarding the Amiga OS, what about 3.5 and 3.9?  Do you know whether H&P used their own atrocious StormC 3 compiler or GCC/StormC 4 or even SAS/C?

AmigaOS 3.5 and 3.9 is mostly SAS/C code also. This is probably because the old projects were SAS/C and, as you know, it takes some effort to convert to a new compiler. The picture.datatype is GCC compiled (has 68060 trapped int 32x32=64 instructions too). There are probably some other GCC utilities but the workbench.library and diskfont.library are SAS/C for example. I don't think any code was compiled with StormC 3. Was StormC 4 (with GCC compiler) out by AmigaOS 3.9? Some of the Warp3D libraries had atrociously bad code that I didn't recognize as GCC code. I didn't know if it was pre-EGCS (2.95) GCC or StormC 3 as I haven't seen much code that bad fortunately.

That would be very handy, I've not really had any experience with Ralph's Barfly or it's GUI debugger but I do like the SAS/C debugger as it "just works".  Well, most of the time anyway. lol

BDebug is my default debugger. It's very powerful but could be easier to use for beginner source level debugging. CPR is also a good debugger and could ease the transition of SAS/C developers to vbbc. Vbbc doesn' have many extra tools like an integrated editor and debugger so this is very important.

Slightly OT question, but would your CopyMem routines be a good fit to merge into the 68k AROS source?  I imagine they'd speed it up a great deal.

I asked Matthias Henze who wrote the HSMathLibs if he'd consider donating the source for his libs to the AROS team because he doesn't get many registrations these days (Though I tell everyone I can to buy them) but he didn't reply to that specific question so I took it as a no.

It's a shame, as there are quite a few performance patches for 68k machines that if the source were donated to AROS could be included in the OS by default and make 68k AROS a much better experience than it currently is.

The WarpDT datatypes come to mind as a random example.

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.

[ChaosLord]

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. Some of those new fancy optimizations work on the Amiga.

No way! :crazy: What happened?  Pigs started flying?  Hell froze over? :mickeymouse:

[nicholas]

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.

Amen to that!