Which 68060.library?

[matthey]

I found some FPU related bugs in ThoR's Mu 68060.library that he will be addressing soon but affect the development of other software. Which 68060 library are users using most?

1) Mu 68060.library (Thomas Richter)
2) Phase 5 68060.library (Ralph Schmidt)
3) Apollo 68060 library
4) GVP-M 68060.library (Ralph Babel and Jeff Boyer)
5) Coenobium Developments 68060.library (Carsten Schlote)
6) Cosmos 68060.library
7) C= 68060.library (this may be an earlier version of option 4)
Other

[matthey]

My 1200 came with an Apollo 060 and the Apollo 68060.library of course.  So I always used that without giving it a 2nd thought.

Is there something wrong with the Apollo 68060.library?

No. It may be slower and there may be some bugs but I'm not sure the Apollo works properly with any other 68060.library. The Apollo hardware is quirky.

I seem to recall that Thor's library utilizes a very clever wrap-around the 4GB memory map trick to get superfast speed.  Which of the other libraries do the same trick?

I hadn't heard that. Do you mean virtually map some code/data to the upper (negative) 32k of addresses so absolute short addressing can be used? What did he put there?

If a person uses WinUAE and they set CPU=68060 then which 68060.library should they use, if any?

And what if they set CPU=68060 + FPU=68882?
(So there are no unimplemented FPU instructions)

I believe UAE will install all the missing instructions of the 68040 or 68060 when these processors are selected. If this is the case, then the answer may be none (installing a 68060.library may be slower). I recommend checking with the UAE documentation though.

Also, does any of this stuff affect OxyPatcher/CyberPatcher ?

OxyPatcher should work with any 68060.library. CyberPatcher may require the P5 68060.library and MuRedox may require the Mu 68060.library but I'm not sure.

[matthey]

Commodore had a 68060.library?

I thought so but maybe they stopped with the 68040.library? I don't even have the C= 68040.library on my HD anymore. It was really slow and the support was not very good. I have the Mu 68060.library installed and the P5 68060.library for backup. They are both fast with good emulation and few bugs. Only ThoR's version is still maintained as far as I know. He should have an update for the FPU emulation related bug I reported when he gets back home in a few weeks .

I've got a Blizzard so I use the Phase 5 68060.library, when I had my Apollo I used the Apollo library.

I did have bit of a play with both Mu and Cosmos library but for speed and stability you can't be the real thing.

The P5 library is fast but the Mu library was a little faster on my P5 CSMK3 when I put the Kickstart in MAPROM with BlizKick and added "MuFastZero MOVESSP ON" to my S:Startup-Sequence. The Mu library also uses and patches the utility.library with my fast integer 32x32=64 code which I don't think the P5 library can match . The P5 library doesn't require the tweaking and configuring that the Mu library does though. In my experience, they are both great choices for anyone that can use them.

[matthey]

ThoR has released a fix for the Mu 68060.library FPU bugs:

http://aminet.net/util/sys/Mu680x0Libs.lha http://aminet.net/package/util/sys/Mu680x0Libs

My tests so far have shown it to be a successful fix. If any one has any problems with it then please send ThoR a report and/or post here.

[matthey]

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.

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?

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

The newest versions should. Peter fixed a few things in the last couple of versions to get it working.

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

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

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

[matthey]

@ThoR
Welcome to amiga.org.

The problem with any optimizations is that it is so easy to get something wrong. The trouble is, a FSIN emulation has to do more than just compute the sine of its argument. It also has to set all condition codes correctly, and return the FPU in exactly the state the "real thing" would have done. Which is more than the result. Just to give you an idea: The fpsp FMOD code looks "needlessly complicated", but in fact is not. Besides the condition codes, the "inexact" flag, the result and testing for special conditions like very large or very small arguments, the FPU also has a (relatively unknown) "quotient byte" that needs to be computed and filled in - correctly. Obviously, if you "just" wanted the remainder to be computed, all that is superfluous. But fpsp does a lot more than that, it emulates the complete instruction with all the consequences - which for the 68060.library *also* means taking traces and emulating a bus error in case you hit unmapped memory.

It sounds like each emulated function would need 1/2 a page or more of documentation specifying requirements, warning about what to avoid and listing changes. The FPU instructions have a lot of variations too. Most errors would go unnoticed with subtle changes in behavior. I was surprised the not so minor bug you just fixed didn't cause more problems. Then again, the vbbc fp->unsigned int and fp<->64 bit int (both ways) conversion functions had major bugs and most programs still worked. Compilers are where we need to fix code so we don't have to call these dinosaurs any more.

[matthey]

Of course 68060FE133 exists.  Duh.
I donno if there is an MC on the front or not.

But it doesn't matter.  The point is they exist and they work.

They have the MC but they are "EC" and SMD only. Here is a close up pick from the Natami site:

http://www.natami.net/gfx/NAe60F/NAe60F_2.jpg

More info here:

http://www.natami.net/hardware.htm

The price may go up soon if they are using a fault tolerant pair of them on the Tomahawk cruise missiles :/.