09 March 2021, 17:17 | #1101 | |
Registered User
Join Date: May 2013
Location: Grimstad / Norway
Posts: 852
|
Quote:
One of the comments I read about the new Mac (and it's soon(?) forthcoming bigger brethren/sisters), is that it is so fast because it can actually issue 8 instructions per cycle, which goes against conventional wisdom that you top out max IPC in the 3 to 4 region. The crux here was that RISC was making a comeback as the complexity of x86/CISC decoding was rising exponentially and as such going further than decoding 4 instructions per cycles was Unobtainium for Intel/AMD. Correct me if I understood it wrong. What I find much more interesting is that Mill Computing are throwing the rulebook about IPC out the window and are aiming way higher at their IPC numbers. They do a lot of stuff to make that happen, both for actual decode and for handling parallellism. |
|
09 March 2021, 17:44 | #1102 | |
son of 68k
Join Date: Nov 2007
Location: Lyon / France
Age: 51
Posts: 5,355
|
Quote:
Also don't forget that theoretical IPC is a maximum. In reality it often drops to a mere 1 because of dependencies. For me that A1 chip is taking the path IBM Power took before - optimize to death and ultimately fail because the advantages of RISC don't work anymore. That doesn't mean ARM won't take over the market - but the reason will not be raw cpu speed. This is an attempt at a nice theory. It does not look like it's being successful in reality. There have been attempts at VLIW, there has been the Cell, and look at where they all are today. |
|
09 March 2021, 17:57 | #1103 |
Registered User
Join Date: Jun 2015
Location: Germany
Posts: 1,924
|
I addressed this point above: they do not issue 3 instructions instead of 1 for doing the same work, they identify a bundle of 3 instructions and then issue this bundle as 1 instruction.
|
09 March 2021, 18:35 | #1104 | |
son of 68k
Join Date: Nov 2007
Location: Lyon / France
Age: 51
Posts: 5,355
|
Quote:
If you do 8 per clock but have to execute 18, you're slower than if you execute 4 per clock and need only 6. |
|
09 March 2021, 18:50 | #1105 | |
Registered User
Join Date: Jun 2015
Location: Germany
Posts: 1,924
|
Quote:
|
|
09 March 2021, 19:21 | #1106 | |
son of 68k
Join Date: Nov 2007
Location: Lyon / France
Age: 51
Posts: 5,355
|
Quote:
|
|
09 March 2021, 19:27 | #1107 |
Registered User
Join Date: Jun 2015
Location: Germany
Posts: 1,924
|
|
09 March 2021, 20:09 | #1108 |
son of 68k
Join Date: Nov 2007
Location: Lyon / France
Age: 51
Posts: 5,355
|
|
10 March 2021, 16:03 | #1109 |
Registered User
Join Date: May 2013
Location: Grimstad / Norway
Posts: 852
|
And right on que I found this today: https://www.osnews.com/story/133140/...ture-research/ which links to https://dougallj.github.io/applecpu/firestorm.html
Whether that proves or disproves anything I don't know. |
10 March 2021, 17:15 | #1110 |
son of 68k
Join Date: Nov 2007
Location: Lyon / France
Age: 51
Posts: 5,355
|
The only sure thing is that another cpu war has begun. Only time will tell how it ends.
|
10 March 2021, 17:34 | #1111 |
Registered User
Join Date: Jun 2015
Location: Germany
Posts: 1,924
|
The bad thing about the Apple chip is that only Apple has it and most probably Apple will keep it to themselves. Other ARM processors aren't likely to kill off x86 any time soon. And Apple isn't going to eliminate x86-based Windows PCs either.
|
11 March 2021, 05:09 | #1112 | |||
Registered User
Join Date: Mar 2018
Location: Hastings, New Zealand
Posts: 2,728
|
Quote:
Quote:
Quote:
|
|||
11 March 2021, 09:04 | #1113 | |
Registered User
Join Date: Jun 2015
Location: Germany
Posts: 1,924
|
Well, one of the two is bad. A lot of manufacturers could benefit from a fast ARM implementation that is as fast as x86 processors but Apple will keep it for themselves and not sell it as a part for others to use. This could even lead to competitors switching from ARM to x86. On the other hand I believe those two markets are already strongly divided and nobody is going to switch because of processor speed. If Apple computers use ARM, well, it is going to be 5% less market share for x86. This doesn't seem a big deal.
Quote:
|
|
20 March 2021, 12:52 | #1114 | |
Registered User
Join Date: Mar 2016
Location: Ozherele
Posts: 229
|
Quote:
|
|
21 March 2021, 04:53 | #1115 |
Registered User
Join Date: Mar 2018
Location: Hastings, New Zealand
Posts: 2,728
|
Commodore was going down anyway, due to PCs taking over the market. After Apple switched to Power PC there was practically no market left for the 68060.
|
23 March 2021, 18:04 | #1116 | |
Registered User
Join Date: Mar 2016
Location: Ozherele
Posts: 229
|
Quote:
We can also dream a little. For example, it was quite possible that a cheap Amiga based on the 68040 might have been released in 1994 or 1995. |
|
23 March 2021, 19:09 | #1117 |
Registered User
Join Date: Mar 2018
Location: Hastings, New Zealand
Posts: 2,728
|
They did. Both the A3000 and A4000 had a CPU board connector (which is how I was able to have a 68060 in my A3000). The A3000 was released in 1991, so you could say they provided for the 68060 quite early on.
The 68060 was released in late 1994 when Commodore was already gone, so there wasn't much else they could have done to 'provide some ground' for it. However they did produce an 040 board for the A4000 which they could easily have modified to take an 060. If Commodore had survived for a few more years I'm betting they would have produced one. Last edited by Bruce Abbott; 28 March 2021 at 03:08. |
27 March 2021, 14:05 | #1118 |
Registered User
Join Date: Jan 2019
Location: Germany
Posts: 3,310
|
There is a strange race condition on the 68060 as in "you cannot restore the CPU state in all conditions". Typically, you want a debugger to be able to save the CPU state, fiddle around with its registers, and then restore the state back to how it was before.
Interestingly, this is not always possible on the 68060, which is really a bizarre exception throughout the motorola series. The condition is as follows: If the FPU is in NULL state, and a non-implemented floating point exception is taken because the first opcode the FPU ever sees is something it does not handle in hardware, then the FPU is still in NULL state, but the FPIAR register points to the instruction to be emulated (has to, actually, as the FPSP code needs to grab and interpret the instruction from there). However, this FPU state cannot be restored. Either, you can place a value back into the FPIAR, but this results in the FPU being in IDLE state, not in NULL state. Or you place the FPU back in NULL state, but then the next read from FPIAR returns 0, not the faulting instruction. This is different from the 68040 - a non-implemented FPU instruction there creates a rather lenghtly exception stack frame and the proper address in FPIAR, and both can be restored. In reality, it does not matter too much whether the FPU is in IDLE or in NULL state, though. For the 68060, the stack frame is the same size anyhow. |
27 March 2021, 14:34 | #1119 | |
son of 68k
Join Date: Nov 2007
Location: Lyon / France
Age: 51
Posts: 5,355
|
Quote:
|
|
27 March 2021, 15:22 | #1120 | |
Registered User
Join Date: Jan 2019
Location: Germany
Posts: 3,310
|
Quote:
In the particular use case, this is not an option. But it does not matter too much, it was rather an observation and a curiousity than a problem statement. |
|
Currently Active Users Viewing This Thread: 1 (0 members and 1 guests) | |
Thread Tools | |
Similar Threads | ||||
Thread | Thread Starter | Forum | Replies | Last Post |
Any software to see technical OS details? | necronom | support.Other | 3 | 02 April 2016 12:05 |
2-star rarity details? | stet | HOL suggestions and feedback | 0 | 14 December 2015 05:24 |
EAB's FTP details... | Basquemactee1 | project.Amiga File Server | 2 | 30 October 2013 22:54 |
req details for sdl | turrican3 | request.Other | 0 | 20 April 2008 22:06 |
Forum Details | BippyM | request.Other | 0 | 15 May 2006 00:56 |
|
|