Turbo9 – A Compact and Efficient Pipelined 6809 Microprocessor IP
github.com
github.com
Well, where is the superscalar variant? :-) At least on an FPGA, there would be very diminishing returns for doing it. Even bypassing has bad effects on fMAX.
https://en.wikipedia.org/wiki/Transport_triggered_architectu...
that convinced me I could build a useful custom processor but it also got me to see how complex things get when you go pipelined, superscalar, depending on a cache, etc.
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.
*looks at massive heat sink and fan on my desktop system...
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 :-)
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_...
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.
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...
(To be clear, I'd like it to work, just questioning the economics.)
I think there's value in an open and modernized 8-bit MCU/MPU that isn't PIC or whatever.
Unfortunately they've had a bad streak in terms of getting a proper GCC or Clang toolchain targeted towards them. The developers of the chip are focused on their own weird structured BASIC-Assembly fusion ("SPIN").
> Current industry trends are to adapt 32-bit RISC IP for microcontroller use, however their large 32x32 register files and loosely encoded instructions limit their absolute minimum footprint. So with the goal of a creating a performance and compact microprocessor IP, we need an 16-bit instruction set architecture (ISA).
Not every application requires 32 bits and as you can see from some of the use cases, there might be a dozen of these in a design so minimal footprint is important.
Couldn't the same be done in a 16-bit architecture? And cut the # of registers. Like 16x 16-bit registers, optionally used as 32-bit pairs (8 of those).
None of this says anything about external memory sizes or such.
Btw: RISC-V has an "-E" flavour which cuts the # of registers in half from 32 to 16, but is otherwise identical. There's even some (unofficial) RV16 candidates out there.
As soon as you create your own architecture, you're essentially a toy. Nobody will want to rely on your half finished C compiler for it, or your unmaintained patchset for LLVM, or be willing to learn verilog just to fill gaps in documentation.
Even something as "simple" as changing registers on RISC-V will break most tooling and make most existing documentation impossible to rely on. Resulting in essentially a new architecture with a confusing name.
Being a toy isn't a bad thing, it just wasn't their goal here.
You'd be very mistaken. 4-bit MCUs are still found in places where you wouldn't even expect an MCU, and the 8-bit ones are numerous in ultra-high-volume highly cost-sensitive applications. Products that use COB-mounted sub-$0.01 die.
Unfortunately 6502, 8051, Z80, and various other architectures from a similar era already fill that niche.
I'm guessing they picked the 6809 because it's a lot more friendly to C than those other architectures.
Too bad though, the 6809 is the pinnacle of 8-bit CPU architecture. It's the result of analyzing the practical shortcomings of the 6800 and other CPUs and redesigning the ISA. It has 16-bit index registers and 16-bit arithmetic, addressing two of the 6502s most annoying drawbacks. Additionally, it has support for stack based locals, position independent code and a LEA instruction. All those make building a high level language compiler much easier than other 8-bits.
http://www.bitsavers.org/components/motorola/_dataSheets/682...
Basically, it can page a couple of megabytes (maybe 4 I can't remember off hand) into and out of the 16 bit address space as 2, 4, 8Kb pages.
The really nice thing is how well the 6809 can do relocatable code. Made paging things in to and out of RAM flexible.
I do recall, I used 2 pages, 16Kb RAM for my projects.
Page one, run main code and page in subroutines as needed. I could put graphics data under the main code too. The draw routines got called in page 2, meaning page 1 could go away for a while.
It worked well. Maybe it was the Atari featuring different page sizes.
How are people putting 2 Megabytes into the machine? I never did one of those upgrades, though I did add a 6309.
That is, it has a 32-bit accumulator (made up of four 8-bit accumulators) but apparently no address extensions.
'816 was a gross hack, but it at least let you get more memory on there without resorting to bankswitching
that and the stupid mode switching
oh, and stack and zero page not being able move out of first bank
not a compelling chip.
The DB was not as flexible as segment registers, and there was only one of them, but you could easily load them both and then get a 16 bit value into the accumulator. Index registers also crossed bank boundaries. In contrast to the 8086, where the segments were a bit of a jail.
Mind, that's a feature in that you could write a multiprocessing system without memory protection, and have code reasonably safe from accidentally stomping on other areas (for example, if your C compiler compiled to the Tiny model, a rogue C ptr shouldn't be able to break out, obviously assembly could do anything).
Regarding the 68K and larger address space, on the original Macintosh, you were unable to request a single block of memory larger than 32K. So, like the Genie, unlimited power -- itty bitty living space. Sure, pointers could access anything, but at a system level, you weren't going to get a large enough chunk of memory, all at once, to warrant a larger pointer, so you were working with almost "virtually" segmented memory anyway.
On the IIGS, based on the 816, they used a similar memory manager. The segment manager on IIGS is really pretty cool. It's 2.0 of what the Macintosh had.