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.
