The 68K Rides Again
![]() |
I hate to keep talking about the 68K, but it keeps popping up in different guises. Apparently the 68K design team made some very, very good architectural tradeoffs. And those choices are still viable, even with today's higher silicon densities and fast clock speeds. The 68K was a classy architecture.
Initially, the 68K was controversial. To some, it was a 16-bit processor—16-bit external data bus, and 16-bit ALU. To others, it was a 32-bitter—32-bit arithmetic, 32-bit registers. Both sides were right. Moreover, the 68K was designed to grow, and it did—into a mainstream 32-bit embedded standard architecture. One key to the 68K's effectiveness was its basic 16-bit, extensible instruction word. The instruction word could be extended with multiple 16-bit words to add needed immediate data, constants, addresses, or address offsets to the instruction.
The 68K had the math advantage of working with 32-bit data, and the density advantage of a basic 16-bit instruction. The combination worked. And the 68K became a leader in high code density and compact code for 32-bitters. To this day, many designers measure code density relative to the 68K.
For an early CISC processor, the 68K set a lot of design standards. For one, it has a generalized register set of 32-bit registers—eight data, seven address, two stack pointers, and a PC, which made it a dream to program. Also, the 68K was pipelined for greater efficiency, with three stages: Fetch, Decode, and Execute. Still, the 68K is a classic CISC, and as such enabled programmers to efficiently access and modify memory data using a single instruction.
Moreover, the 56800 doesn't act like a RISC. It is not a RISC Load/Store architecture, where all processing is on registers. Instead, like the 68K, it can manipulate values in memory, including a Read-Modify-Write. This memory approach minimizes register use, so you need fewer registers to hold input or intermediate values. It also translates to less instructions and higher code densities.
Similarly, the 568xx's extensible 16-bit word minimizes memory usage. Instead of a 24-bit or 32-bit word, you can make do with a 16-bit basic instruction word. If you need more, the instruction can be extended with additional carrier words, giving the 568xx code densities approaching those of its 68K ancestor.
Unlike most 4th generation DSPs, the Star-Core has a short five-stage pipeline to minimize interrupt and branch latencies. It can manipulate memory-stored values directly using instructions such as bit manipulation. This direct memory modify approach minimizes instructions and is very valuable for control application code that needs control state held in memory.



Loading comments... Write a comment