Hacker News Reader

Comment by userbinator | Hacker News Reader

Maybe Motorola could have pulled off what Intel did with Pentium, paper over the aging CISC with RISC internals, but instead we got PowerPC.

I think one of the factors could be that 68k is a bit harder to decode than x86 - while the instruction set is more orthogonal, the encoding has less structure; compare http://goldencrystal.free.fr/M68kOpcodes.pdf (68k) with http://i.stack.imgur.com/07zKL.png (x86).

very fast (single CPU cycle) memory access

That was possible only because at the time, memory was faster than the core and could keep up. Modern CPUs run the core at several times memory speeds, and there is latency involved due to physical constraints.

View on HN

One difference between Motorola and Intel, is Motorola was less concerned with breaking backwards compatibility.

If the 68k family had continued to evolve past the 1994s 68060, I'm sure they could have just dropped backwards compatibility to some of the more complex addressing modes, or just devoted less silicon to them, and making what remains faster. Kinda like happened with the ColdFire version of the 68k family.

The not-implemented instruction trapping in the 68K could be easily evolved to cover less frequently used instructions to make room for more optimized implementations of the frequently used ones.

What really killed the 68000 was the move to RISC, in particular Apple's move to PowerPC. That took away any hope of future evolution (they even managed to release the 68060 after that, but that was it) and collapsed the high-end 68K business.

Note that Motorola also did the m88k which was their RISC approach. It generated a bit of interest, but was never successful. https://en.wikipedia.org/wiki/Motorola_88000

The Motorola Series 900 machines were interesting - I had one under my desk at work for quite a while. They had stackable units, including one that contained a SCSI 3.5" floppy drive that was way faster than regular ones. We also had a DG unit with the m88k.

A lot of what was the 88K was put into the PowerPC.

Yep. The one thing Intel frets over these days is cache misses. Hyperthreading is all about keeping that pipeline busy even if the original thread encounter a cache miss.

> very fast (single CPU cycle) memory access

> That was possible only because at the time, memory was faster than the core and could keep up. Modern CPUs run the core at several times memory speeds, and there is latency involved due to physical constraints.

That begs the question: Would we be better off if CPU clock speeds were set such that the memory could keep up again, and we software developers learned to work within real constraints again, rather than expecting the CPU makers to keep working miracles to deliver ever more performance? I have no wish to go back to programming in Applesoft BASIC or 6502 assembler as I did in my childhood and early teenage years. But programming a 32-bit processor clocked to match the speed of memory, in C++ or Rust, wouldn't be so bad.

> That begs the question: Would we be better off if CPU clock speeds were set such that the memory could keep up again

Memory latency is at best about 10 ns. I don't think a 100 MHz CPU would better in any way than what we have now. Well, except power requirements would sure be very low.

Would we be better off if CPU clock speeds were set such that the memory could keep up again

Absolutely not, because of the locality principle. As Terje Mathisen used to say, "All programming is an exercise in caching."

Locality isn't a property of a specific coding style or methodology, it's just the way programs work. No matter what kind of architecture we end up using 50 years from now, it will have a fast cache of some kind, backed up by slower memory of some kind. We'll have a different set of problems to confront in day-to-day development work, but hobbling the CPU won't be the answer to any of them.

Sure, caching is important. But today, we have multiple layers of cache: registers, L1, L2, sometimes L3, and RAM, all of which are caches for nonvolatile (increasingly flash) storage. All of that layering surely has a cost. So what would we get if a processor with no caches between registers and RAM were manufactured using a current process (say, 14 nm), clocked such that DRAM could keep up (so, 100 MHz if another comment on this thread is accurate), and placed on a board with enough RAM for a general-purpose OS as opposed to an RTOS for a single embedded application? Would the net result be any more power efficient than the processors that smartphones use now?

L1/L2 cache levels are transparent optimizations over the top of register--ram, so eliminating them in a RAM-bound application would save you transistors (power usage) without losing performance. But although a few certain RAM-bound applications might perform equivalently, you've destroyed all other classes of application in the process.

Power efficiency is more complex, often it's better to briefly burst then get back to sleep faster, rather than drag things out at 100 MHz, but a specific answer would depend on many factors.

Reply on news.ycombinator.com