Oooh. 6809 resurrection project. I studied that arch obsessively when I was a kid with a Tandy Color Computer.
I had a Coco 1 and a Coco 3, with the OS-9 operating system you could run C and Pascal compilers as well as use BASIC09 which was like a modern bytecode interpreted language (Python). The 6809 stands out because it was designed to support compiled languages, shared libraries and such. It not only had the right addressing modes but it had just enough registers that code generation was straightforward.
When I replaced my Coco3 with a 286 machine I switched to hardware that was more than an order of magnitude faster but MS-DOS was a big step back from OS-9.
Lately I have been obsessed with the lost 24-bit generation of micros and was quite delighted to discover the eZ80, would be nice to see the 6809 follow the same route but Motorola was too committed to the ultimately doomed 68k.
It was a great ISA (though clearly completely different from the 6809), and these days big endian looks like a serious anachronism.
Every company that invested in it, however, had to either go out of business or switch to another architecture, usually the first. Apple and Sun Microsystems survived. Fragmentation, with the Apple Macintosh, Amiga, Atari ST, Sinclair QL, etc. (all similar machines that struggled with cost-performance tradeoffs in different ways), didn't help.
The BBC Micro developers probably had more space to really think about how to make a home computer and looked at many architectures and came to the conclusion that the 68k line punched below its weight. People in the early 1980s didn't see that one of the greatest rugpulls in computing was coming and were blindsided by IBM "doing it again" by maintaining long-term software compatibility with the 8088 and derivatives the way they did for the old 360... Companies that invested in the x86 didn't regret it, though many of them were crushed by an increasingly competitive market.
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 :-)
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.
And x86 will, too, be replaced.
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.
I'm sure the 68020 was better.
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.
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.
At 1MHz, sure.
Obviously in throughput, a different story
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_...
*looks at massive heat sink and fan on my desktop system...
This was after I had purchased and fully digested the only documentation I could find: "OS-9 Insights"
https://www.amazon.com/OS-9-insights-advanced-programmers-gu...