25 October 2022, 11:28 | #181 |
Registered User
Join Date: Mar 2004
Location: finland
Posts: 1,843
|
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 |
25 October 2022, 14:37 | #182 | |
Banned
Join Date: Oct 2021
Location: SA
Posts: 283
|
Quote:
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 |
|
25 October 2022, 20:44 | #183 | |
Registered User
Join Date: Jan 2008
Location: Warsaw/Poland
Age: 56
Posts: 2,048
|
Quote:
|
|
25 October 2022, 22:04 | #184 | |
Banned
Join Date: Oct 2021
Location: SA
Posts: 283
|
Quote:
but in the 99.9 % of the 68k programs and games : the 040 and 060 perform idem per clock |
|
25 October 2022, 22:07 | #185 | |
Going nowhere
Join Date: Oct 2001
Location: United Kingdom
Age: 50
Posts: 9,017
|
Quote:
They typically utilise lots of byte instructions which are not where an 040 or 060 perform at their best. |
|
27 October 2022, 15:49 | #186 |
Registered User
Join Date: May 2007
Location: Austria
Posts: 67
|
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.
|
27 October 2022, 15:53 | #187 |
Registered User
Join Date: May 2007
Location: Austria
Posts: 67
|
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.
|
27 October 2022, 16:51 | #188 | |
Banned
Join Date: Oct 2021
Location: SA
Posts: 283
|
Quote:
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 |
|
27 October 2022, 17:34 | #189 | |
Registered User
Join Date: Jun 2009
Location: Dublin, then Glasgow
Posts: 6,381
|
Quote:
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. |
|
27 October 2022, 20:16 | #190 |
Registered User
Join Date: May 2007
Location: Austria
Posts: 67
|
@Daedalus:
Thanks for explaining! |
28 October 2022, 10:56 | #191 | |
Registered User
Join Date: Jan 2019
Location: Germany
Posts: 3,317
|
Quote:
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. |
|
28 October 2022, 19:46 | #192 |
Registered User
Join Date: May 2007
Location: Austria
Posts: 67
|
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. |
03 November 2022, 03:00 | #193 |
Registered User
Join Date: Dec 2013
Location: Lake Havasu City, AZ
Posts: 741
|
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. |
03 November 2022, 06:17 | #194 |
Banned
Join Date: Oct 2021
Location: SA
Posts: 283
|
|
03 November 2022, 10:31 | #195 |
-
Join Date: Jul 2003
Location: Helsinki / Finland
Age: 43
Posts: 9,918
|
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.
|
03 November 2022, 17:15 | #196 | |
Registered User
Join Date: Jan 2019
Location: Germany
Posts: 3,317
|
Quote:
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. |
|
03 November 2022, 21:57 | #197 |
Registered User
Join Date: Dec 2013
Location: Lake Havasu City, AZ
Posts: 741
|
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. |
04 November 2022, 12:11 | #198 | |
Registered User
Join Date: Jan 2019
Location: Germany
Posts: 3,317
|
Quote:
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. |
|
04 November 2022, 15:47 | #199 |
Banned
Join Date: Oct 2021
Location: SA
Posts: 283
|
|
04 November 2022, 17:25 | #200 |
Registered User
Join Date: Jan 2019
Location: Germany
Posts: 3,317
|
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. |
Currently Active Users Viewing This Thread: 1 (0 members and 1 guests) | |
Thread Tools | |
Similar Threads | ||||
Thread | Thread Starter | Forum | Replies | Last Post |
Fusion MAC emul back to wb keys | clauddio | support.Apps | 0 | 15 March 2012 02:35 |
Fusion Mac emu | DDNI | request.Apps | 47 | 12 March 2009 01:21 |
Mac emulator Fusion | panos_pit | request.Apps | 2 | 26 October 2008 15:58 |
Were to get Mac os for emulator? | adonay | request.Other | 12 | 28 February 2008 16:07 |
Damn Mac games fly in Fusion!! | DDNI | Amiga scene | 1 | 04 June 2007 01:44 |
|
|