View Single Post
Old 27 February 2017, 21:20   #38
matthey
Banned
 
Join Date: Jan 2010
Location: Kansas
Posts: 1,284
Quote:
Originally Posted by idrougge View Post
It's not surprising that success rates were high when they were making a chip with so few transistors. Even if we say that the 6502 is "superior", it is not more advanced than the competition. It gained its advantage by being simple instead of advanced.
Chuck Peddle had a goal (vision) to lower the cost of microprocessors so they could be used in many more applications. It was his philosophy at MOS to actively look for and encourage improvements which made the mask process improvements possible. Other big companies were ignoring R&D and happy to collect customer money from their large market shares. They didn't want him rocking the boat (he was reprimanded at Motorola for suggesting and pushing for improvements) but he was right and his vision revolutionized and help pioneer the microprocessor market. C= would likely not have made personal computers without him. He played two huge rolls in making microprocessors affordable and personally persuading Jack Tramiel to make computers at C=. Without him, we likely would not be having this conversation.

Quote:
Originally Posted by idrougge View Post
You also seem to forget Intel's super-CISCy processor, the iAPX 432.
According to the New York Times, "the i432 ran 5 to 10 times more slowly than its competitor, the Motorola 68000".

Intel learned a lot from trial and error. This iAPX (432) mistake is hardly an example of Intel Expertise with CISC but rather a good example to the contrary. This is the kind of project that could bankrupt a company as it likely cost much more than the 8080 to 8086 upgrade project where they were lucky with IBM choosing the 8088 (8086 variant).

IMO, Intel was no expert even up to the Pentium days. They were lucky again that texture mapped "desktop" gaming was pushing PC sales where energy efficiency wasn't important. Let's compare the Pentium and 68060.

Pentium@75MHz 80502, 3.3V, 0.6um, 3.2 million transistors, 9.5W max
68060@75MHz 3.3V, 0.6um, 2.5 million transistors, ~5.5W max*

* estimate based on 68060@50MHz 3.9W max, 68060@66MHz 4.9W max

The 68060 integer performance is known to be a little better at the same clock speed than the Pentium despite more conservative MIPS numbers from Motorola (perhaps due to inferior 68k compilers). The Pentium had higher theoretical FPU performance at the same clock speed despite its inferior FPU stack based ISA because the 68060 did not have a fully pipelined FPU but more common mixed FPU and integer code reduced this Pentium advantage. The 68060 is using ~42% less power to give similar performance with the most comparable chips chosen. Both processors are in order superscalar with only 8kB ICache and 8kB DCache. This is similar to the in order superscalar Intel Atom which Intel was trying to get down to the energy efficiency of ARM and actually did (OoO Cortex A9 while outperforming it) according to this article.

https://research.cs.wisc.edu/vertica...-struggles.pdf

What if a CPU design based on the 68060 used 42% less power than the Atom processor that beat the very common ARM Cortex A9? What if Motorola abandoned and sabotaged (by anti-marketing and not clocking up) the 68060 without recognizing its full potential? What if ARMv8 is making a mistake for embedded and mobile by going bigger when it is unnecessary and smaller is faster?

P.S. I wanted to compare the PPC 601@75MHz 3.3V, 0.6um, 2.8 million transistors but could no longer find power dissipation numbers. The PPC 601 was considerably slower at the same clock speed than the 68060 and Pentium despite having twice the caches (32kB unified L1). The shallow pipeline OoO PPC is generally power efficient and the base CPU is small in transistor count but this advantage is lost with larger caches and memory power requirements and transistor counts necessary to add performance. IBM created the PPC 405GP embedded CPU with CodePack code compression but this style of code compression still requires a large L1 ICache which CISC innate compression does not.

Last edited by matthey; 27 February 2017 at 21:27.
matthey is offline  
 
Page generated in 0.12843 seconds with 11 queries