Which 68060.library?

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

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

[guest11527]

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.

First of all, thanks to Matt for reporting bugs, which finally got fixed.

To answer the last question: MuRedox requires the mmu.library and the fpsp.resource, so "technically speaking" it does not require the 68060.library from the MMU project. However, since that's the only library that offers the fpsp.resource... The point is, when writing MuRedox and updating the mathieee... libs, I shurely didn't want to re-invent the wheel and re-implement emulation code for math instructions, even more so as all the code was already there, and tested. Thus the resource.

[guest11527]

A new 68060.library version for Phase5 boards is actually on test here :

 68060.library v46.21

  - v46.20 -> v46.21
  - Removed Cyberpatcher support (users must use the very better OxyPatcher)
  -  Added faster Autovectors (http://leblogdecosmos.blogspot.fr/2012/05/code-optimisation-iii.html)
  - _ffloord optimized (mathieeedoubtrans.library)
  - _fceild optimized (mathieeedoubtrans.library)
  - _fsind optimized (mathieeedoubtrans.library)
  - _fcosd optimized (mathieeedoubtrans.library)

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.

So, in general, this is a big "hands off" unless you know precisely what you're doing. That said, given the bugs Matt detected, I neither do that.

[Gulliver]

I voted "Other" in the poll.
My main system is a Macrosystem DraCo and it uses a custom 68060.library called DraCo060Emu (see attachment).

I would like to use a more current one, not so obscure, and still supported 68060.library like the one from Thomas Richter, but I am afraid I could make a bad choice and break something, since a DraCo is quite an obscure system in many aspects.

Any suggestion is welcomed.

[Cosmos Amiga]

The problem with any optimizations is that it is so easy to get something wrong.

The worst anyone can do on Amiga Classic is doing nothing...

Clever guys help me to improve again and again this library (or other) and stupid guys blablabla on forum...

[Ratte]

Thomas technical description is very interresting.

[guest11527]

The worst anyone can do on Amiga Classic is doing nothing...

Clever guys help me to improve again and again this library (or other) and stupid guys blablabla on forum...

Excuse me, but since when do I "bla bla" without doing anything... (-: It's low profile, slow going since I've a lot of other things to do these days, but if you want to do something truely useful, document what it takes to support P5 hardware since that you have apparently successfully reverse engineered it, or even have sources.

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

[Crumb]

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

[Ratte]

@thomas: pls. update your lha-archiver, your lib has a 1980-datestamp

[nicholas]

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

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

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

[Ratte]

Code: [Select]

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Date:   March 1994

Readme file for the 060 Software Package -- Beta Release B1 --

Read the fpsp.doc, fplsp.doc, isp.doc, ilsp.doc and test.doc
files for information about these different packages.

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Files in this directory:
-------------------------

fpsp.sa         Full FP Kernel Module - hex image
fpsp.s          Full FP Kernel Module - source code
fpsp.doc        Full FP Kernel Module - on-line documentation

pfpsp.sa        Partial FP Kernel Module - hex image
pfpsp.s         Partial FP Kernel Module - source code

fplsp.sa        FP Library Module - hex image
fplsp.s         FP Library Module - source code
fplsp.doc       FP Library Module - on-line documentation

isp.sa          Integer Unimplemented Kernel Module - hex image
isp.s           Integer Unimplemented Kernel Module - source code
isp.doc         Integer Unimplemented Kernel Module - on-line doc

ilsp.sa         Integer Unimplemented Library Module - hex image
ilsp.s          Integer Unimplemented Library Module - source code
ilsp.doc        Integer Unimplemented Library Module - on-line doc

fskeleton.s     Sample Call-outs needed by fpsp.sa and pfpsp.sa

iskeleton.s     Sample Call-outs needed by isp.sa

os.s            Sample Call-outs needed by fpsp.sa, pfpsp.sa, and isp.sa

ftest.sa        Simple test program to test that {p}fpsp.sa
                was connected properly; hex image
ftest.s         above test; source code

itest.sa        Simple test program to test that isp.sa was
                connected properly; hex image
itest.s         above test; source code

test.doc        on-line documentation for {i,f}test.sa

README          This file

ERRATA          Known errata for this release
Did Commodore ever released some o6o-stuff out of the early moto-beta-archive?

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

[nicholas]

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.

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.