3 ms·

I absolutely agree that Motorola fucked up bigtime with the 68k->88k->PPC transition. They listened to the pundits who said the CISC ISA couldn't scale, and the

I absolutely agree that Motorola fucked up bigtime with the 68k->88k->PPC transition. They listened to the pundits who said the CISC ISA couldn't scale, and then Intel proved that (mostly) wrong but it was too late for 68k/ColdFire then. The rug-pulling actually is probably in large part responsible for both Atari and Commodore just packing it in, and led to Apple being in the wilderness for a decade as they did the first of 3 ISA transitions for the Mac. Also yes the 68k was clearly a dog when it came to interrupt responsiveness and made no sense in home computers or video games, at least not until the '020. It was meant to be a bargain VAX. And that's why I say it was influential. A whole generation (X) of us grew up who could never hope (or care) to touch a VAX, but we had Atari STs, Amigas, etc at home, and were shelling into SunOS 68k boxes for fun or school etc. It lasted quite a while after VAX was a done deal, too. To me 68k was the Unix workstation and hobbyist market and defined 32-bit ISAs as well. I never touched an x86 until I could run Linux on it. I've never learned or written x86 assembly seriously in my entire career despite writing (and enjoying) 6502 68k, ARM, MIPS, RISC-V, others Outside of the UK, ARM didn't play a role except for in some embedded stuff. Obviously that changed :-)

KerrAvon 2y ago
We need to remember that everyone -- not just Motorola -- thought CISC was a dead-end by the late 1980's. Even Intel! And we also need to acknowledge that everyone was RIGHT! Intel ultimately threw billions into keeping x86 competitive, and they seem to have finally hit the wall now with performance per watt measures, which is what cost them Apple's business and is now driving Microsoft to ARM.
- snvzz 2y ago
  >And we also need to acknowledge that everyone was RIGHT! And x86 will, too, be replaced.
snvzz 2y ago
>Also yes the 68k was clearly a dog when it came to interrupt responsiveness and made no sense in home computers or video games, at least not until the '020. In what world? The interrupts were very fast, taking just a few cycles, and the behavior was deterministic. This is why they were popular in realtime applications, and remained so for decades. Back in the day, they were famously used in e.g. the Eurofighter Typhoon.
- tom_ 2y ago
  The worst case interrupt latency on the original 68000 is pretty terrible? The instructions take ages and the interrupt handling mechanism adds additional delays. I'm sure the 68020 was better.
  - snvzz 2y ago
    >The worst case interrupt latency on the original 68000 is pretty terrible? It has a fixed cost of 44 cycles. Is this somehow bad? I would call it extremely tight. edit: 44 cycles... after the previous instruction finishes. Some instructions (infamously slow division, and many-reg movem) can be slow. Worst case is what matters for realtime, but it is still under 400 cycles.
    - cmrdporcupine 2y ago
      In home computers and video games? Holy crap ... compare that to the 6502. Maximum 13 cycles, including the execution of the instruction that initiated it, and the return from the interrupt... And yes, obviously that's easy when you only have 3 registers ... But this has a serious real world effect for things like video games.
      - snvzz 2y ago
        >But this has a serious real world effect for things like video games. At 1MHz, sure.
        cmrdporcupine 2y ago
        Well, sure ... and also plaid a part in making an 8mhz Atari ST feel more sluggish than a 1mhz C64 in some things. Obviously in throughput, a different story
        snvzz 2y ago
        Atari ST (68k at 8MHz) had other issues that made it sluggish. It is no Amiga. In most scenarios, most interrupts aren't going to interrupt divisions, as most instructions aren't over 16 cycles[0], thus most interrupts will not be much longer than 44 cycles. In microseconds, a non-issue for a microcomputer. Realtime programmers of the time had predictable behavior, and could simply avoid using the specially long instructions (movem and div) altogether if they needed to bound latency below the upper limit. Performance isn't as important as meeting hard deadlines. 0. https://wiki.neogeodev.org/index.php?title=68k_instructions_timings https://wiki.neogeodev.org/index.php?title=68k_instructions_...

KerrAvon 2y ago

We need to remember that everyone -- not just Motorola -- thought CISC was a dead-end by the late 1980's. Even Intel! And we also need to acknowledge that everyone was RIGHT! Intel ultimately threw billions into keeping x86 competitive, and they seem to have finally hit the wall now with performance per watt measures, which is what cost them Apple's business and is now driving Microsoft to ARM.

snvzz 2y ago
>And we also need to acknowledge that everyone was RIGHT! And x86 will, too, be replaced.

snvzz 2y ago

>Also yes the 68k was clearly a dog when it came to interrupt responsiveness and made no sense in home computers or video games, at least not until the '020. In what world? The interrupts were very fast, taking just a few cycles, and the behavior was deterministic. This is why they were popular in realtime applications, and remained so for decades. Back in the day, they were famously used in e.g. the Eurofighter Typhoon.

tom_ 2y ago
The worst case interrupt latency on the original 68000 is pretty terrible? The instructions take ages and the interrupt handling mechanism adds additional delays. I'm sure the 68020 was better.
- snvzz 2y ago
  >The worst case interrupt latency on the original 68000 is pretty terrible? It has a fixed cost of 44 cycles. Is this somehow bad? I would call it extremely tight. edit: 44 cycles... after the previous instruction finishes. Some instructions (infamously slow division, and many-reg movem) can be slow. Worst case is what matters for realtime, but it is still under 400 cycles.
  - cmrdporcupine 2y ago
    In home computers and video games? Holy crap ... compare that to the 6502. Maximum 13 cycles, including the execution of the instruction that initiated it, and the return from the interrupt... And yes, obviously that's easy when you only have 3 registers ... But this has a serious real world effect for things like video games.
    - snvzz 2y ago
      >But this has a serious real world effect for things like video games. At 1MHz, sure.
      - cmrdporcupine 2y ago
        Well, sure ... and also plaid a part in making an 8mhz Atari ST feel more sluggish than a 1mhz C64 in some things. Obviously in throughput, a different story
        snvzz 2y ago
        Atari ST (68k at 8MHz) had other issues that made it sluggish. It is no Amiga. In most scenarios, most interrupts aren't going to interrupt divisions, as most instructions aren't over 16 cycles[0], thus most interrupts will not be much longer than 44 cycles. In microseconds, a non-issue for a microcomputer. Realtime programmers of the time had predictable behavior, and could simply avoid using the specially long instructions (movem and div) altogether if they needed to bound latency below the upper limit. Performance isn't as important as meeting hard deadlines. 0. https://wiki.neogeodev.org/index.php?title=68k_instructions_timings https://wiki.neogeodev.org/index.php?title=68k_instructions_...