Fusion Mac Emulator

[zipper]

68060 has dual integer execution pipelines,
on-chip floating-point unit (FPU), and branch target cache. A high degree
of instruction execution parallelism is achieved through the use of a full
internal Havard architecture, multiple internal buses, independent execu-
tion units, and dual instruction issue within the instruction execution
controller.

Nobody says dual cores.

https://www.amigareport.com/ar114/p1-10.html

[Marce]

Originally Posted by zipper

68060 has dual integer execution pipelines,
on-chip floating-point unit (FPU), and branch target cache. A high degree
of instruction execution parallelism is achieved through the use of a full
internal Havard architecture, multiple internal buses, independent execu-
tion units, and dual instruction issue within the instruction execution
controller.

Nobody says dual cores.

https://www.amigareport.com/ar114/p1-10.html

such link contains lot of incorrect data, also was written by an amiga fan, not written by motorola or someone serious
it says there:: (Three Times the Performance of a 25-MHz MC68040)

which is not true, is just 2x the performance of the 68040/25mhz

this can be checked by running certain 68k programs which takes certain time to finish ...ie a cruncher, a picture converter, a mp3 decoder etc

on the 060/50 mhz :

will take half the time of the 040/25
or aprox 0.75% of the time of a 68040/40mhz
or aprox 0.10 % of the time of a 020/28mhz
and so on

[Don_Adan]

Originally Posted by Marce

such link contains lot of incorrect data, also was written by an amiga fan, not written by motorola or someone serious
it says there:: (Three Times the Performance of a 25-MHz MC68040)

which is not true, is just 2x the performance of the 68040/25mhz

this can be checked by running certain 68k programs which takes certain time to finish ...ie a cruncher, a picture converter, a mp3 decoder etc

on the 060/50 mhz :

will take half the time of the 040/25
or aprox 0.75% of the time of a 68040/40mhz
or aprox 0.10 % of the time of a 020/28mhz
and so on

But you know that you are wrong? 68060 can be much fastest on this same clock than 68040. This is dependent to used code only. If main routine used many 32 bit multiplications 68060 can be over 5 times fastest than 68040 at same clock. But if main routine used many 64 bit multiplications 68060 will be much slower than 68040. And if main code used many movep instructions then 68060 can be slowest than 68000.

[Marce]

Originally Posted by Don_Adan

But you know that you are wrong? 68060 can be much fastest on this same clock than 68040. This is dependent to used code only. If main routine used many 32 bit multiplications 68060 can be over 5 times fastest than 68040 at same clock. But if main routine used many 64 bit multiplications 68060 will be much slower than 68040. And if main code used many movep instructions then 68060 can be slowest than 68000.

yes perhaps if u write a program strictly designed for the 060 perhaps will be faster
but in the 99.9 % of the 68k programs and games : the 040 and 060 perform idem per clock

[Galahad/FLT]

Originally Posted by Marce

yes perhaps if u write a program strictly designed for the 060 perhaps will be faster
but in the 99.9 % of the 68k programs and games : the 040 and 060 perform idem per clock

You cannot use something like a cruncher or decruncher to prove 060 can't be significantly faster than 040.

They typically utilise lots of byte instructions which are not where an 040 or 060 perform at their best.

[Grex]

And it should also be mentioned, that the cache of the 060 is twice as big as the cache of the 040. And even though I have no clue what the term "SuperScalar" means, the 060 has it, the 040 not. I guess it must be good for something.

[Grex]

Moreover the 060 emulates more instructions in software than the 040 does. This is a disadvantage of course, but it also means that benchmarks will depend on the use of stuff like OxyPatcher/MuRedox/CyberPatcher or the HS-MathLibs.

[Marce]

Originally Posted by Grex

Moreover the 060 emulates more instructions in software than the 040 does. This is a disadvantage of course, but it also means that benchmarks will depend on the use of stuff like OxyPatcher/MuRedox/CyberPatcher or the HS-MathLibs.

those tools ie oxypatcher etc I think they enhance the FPU of the 060 , I remember the program LAME mp3 encoder benefit from those

and fact is that the FPU of the 060 is 2 or 3 x faster that the FPU of the 040
but not on integer which are idem per clock

[Daedalus]

Originally Posted by Grex

And it should also be mentioned, that the cache of the 060 is twice as big as the cache of the 040. And even though I have no clue what the term "SuperScalar" means, the 060 has it, the 040 not. I guess it must be good for something.

Superscalar means it can execute multiple instructions in parallel once the code is suitable. This means that it can have quite a significant advantage over the 68040, even in integer operations.

Aside from the superscalar architecture, instruction timings are different between the two CPUs, so while they may be similar in worst-case scenarios, they're still not identical even when superscalar execution and caches are disabled. In general use, the 68060 will be faster for a given clock speed.

[Grex]

@Daedalus:

Thanks for explaining!

[Thomas Richter]

Originally Posted by Grex

Moreover the 060 emulates more instructions in software than the 040 does. This is a disadvantage of course, but it also means that benchmarks will depend on the use of stuff like OxyPatcher/MuRedox/CyberPatcher or the HS-MathLibs.

Err, not quite. Actually, the 68060 also has one additional instruction in hardware the 68040 does not. (fpint if I recall), but one after the other...

So, first the 68060 has two integer instructions emulated, namely 64 bit multiplication and division the 68040 had in hardware. They are not taken care of by any "math library" as they are integer instructions. MuRedox takes care of them if installed, but both insructions are rarely used.

You do not need any "high speed" math libraries to prevent the emulation trap. All you need are the standard Os math libraries from Os 3.9 or later (3.1.4, 3.2) and a 68040 or 68060.library that creates the "fpsp.resouce" which contains vectors to the emulation. The MuLib-based CPU-libraries do that, and hence provide you with mathematics functions without the need for an emulator trap. Actually, I would not recommend any other math libraries, numerics is sometimes a bit of a black art...

So, to conclude: Both the 68040 and 68060 require software support for floating point. This is taken care of by the FPSP functions from motorola, and these functions come into the system by the CPU libraries (68040 or 68060 library). Some cpu libraries even expose these functions to the outside by means of the "fpsp.resource".

The math instructions where the CPU needs help are the transcendental functions (like sin,cos, exp, log...) and in addition, when the source of a math operation is "denormalized", i.e. out of range. For the 68040, there is one instruction more the CPU cannot perform.

The 68040 also performs all the deocding of the instructions like computing the effective address where to take the floating point number from. For the 68060, the 68060.library has to do this all itself, essentially a full disassembly is required.

For the 68060, also some integer instructions require emulation, namely 64 bit math, and the CAS2 and MOVEP instructions. All of which are rarely needed. This is also taken care of by the 68060.library, but there is no resource to expose their functionality. Actually, they are fairly trivial to emulate.

[Grex]

Okay, I just had read that somewhere (more emulations on 060), but of course you surely know better than me or anyone else in this thread.

This is getting off-topic anyway.

[JimDrew]

The 060 is junk.

It's amazing that I got the Mac to work at all with the 060, but it is severely crippled to even do it. My 40MHz/040 system is almost always faster than a 50MHz 060 setup because of the tremendous number of patches I had to do dealing with the caches and Superscalar mode.

But, I have greatly improved the 060 performance recently with the changes needed for EMU68.

[Marce]

Originally Posted by JimDrew

The 060 is junk.

.

that's right
but some members still believes in old Amiga' myths and fantasies yet they think the 060 is a core i9

[Jope]

Yeah, I also feel there really is no middle ground here. Only beating a core i9 and doing blazingly fast mac emulation are valid reasons for any m68k CPU's existence. If it can't handle those, then there's no hope for it.

[Thomas Richter]

Originally Posted by JimDrew

The 060 is junk.

But, I have greatly improved the 060 performance recently with the changes needed for EMU68.

MacOs is junk.


To be more serious, the underlying problem is of course more MacOs than the 060, and the outdated memory model it is based on. Unlike on Amiga, there is no "CacheClearU()" function, so whenever you copy memory around, caches need to be flushed. Unfortunately, MacOs moves a lot of memory around, which is part of its design, and thus a great deal of the advantage of the caches are lost.

[JimDrew]

The MacOS' memory handling is far superior to the Amiga. There is never any memory fragmentation so you always have the remaining amount of memory as one contiguous block of memory that can be allocated.

The MacOS does have a CacheClearU() type of function. That actually is one of the problems - it is over-used by a LOT of things, most often when not even necessary. But because the MacOS can move entire applications around in memory in real time you have to at very least clear the instruction cache frequently. It's like running self modifying code constantly in some cases. Its super easy to just always clear the caches or turn them off, because everything works. In the case of EMU68 the penalty for doing this is staggering compared to the potential. As a by-product of fixing this, the 060 got faster.

[Thomas Richter]

Originally Posted by JimDrew

The MacOS' memory handling is far superior to the Amiga. There is never any memory fragmentation so you always have the remaining amount of memory as one contiguous block of memory that can be allocated.

Unless the running application runs out of heap space. The MacOs memory manager hasn't aged well, the trouble being that it is quite ill-suited for the multi-finder, which was bolted on top of the system later on. One application can have a fixed amount of heap space, defined in its bundle. If that's out, you're done. If you forgot that your resource is addressed through handle, and just held a pointer to it, well, bad luck of the Os decides to defragment the heap.



All the handle pointers and defragmentation sounded nice when the Mac was single-threaded and based on a 68000 processor without MMU, so they came up with this nice system of resources that could be swapped in and out of memory without hardware support just by double-indirection, but the concept simply didn't carry over well to later processors and the multi-finder.


The problem of fragmenting memory you would solve today (or even yesterday) by the MMU without having to relocate pointers (through the handles), and of course Apple got rid of this handle system in later systems as it is just inconvenient.

[Marce]

Originally Posted by Thomas Richter

MacOs is junk.


.

workbench is junk

it does not have any memory protection, you end up in GURU very often

[Thomas Richter]

Surprise, suprise. MacOs doesn't have any memory protection either. While I certainly appreciate the design aspects of the MacOs memory manager - after all, it had quite some interesting ideas of implementing something like "virtual memory" without virtual memory, the MacOs "multifinder" was really an interesting stunt. The memory manager didn't age well since it does not play well with later CPUs, and its static heap allocation (every application gets a static heap it cannot grow beyond, except for some "special" memory you can request in later versions).

To understand the issue MultiFinder has, some backgrounds: MacOs has 32K of operating system globals, the lowest 32K of memory (thus, "MuMove4K PrepareEmul") compared to the 4 byte globals AmigaOs has ("AbsExecBase"). These globals are not only system variables, but also incude the jump addresses of the LineA traps MacOs uses to interface the kernel from applications. Every application can replace or patch into these traps (roughly, "SetFunction()" on Amiga side).

Now, the stunt is that if Multifinder is active, every application running requires of course its own globals, and may also install its own patches. Thus, whenever the MultiFinder schedules applications, it undoes all the patches (LineA trap replacements) one application did, and re-installs those from another. Similar, MacOs globals (some of them) are replaced either. Hence, multitasking on MacOs is rather a heavy-duty operation compared to the 40 lines scheduler AmigaOs has.

Maybe that explains a little bit better what I mean by "Multifinder was bolted on top of MacOs". It is not a very elegant construction.