The 68K Rides Again

Ray Weiss

May 19, 2000

Ray Weiss

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.


Motorola's DSP56800
Not surprisingly, Motorola designers took the 68K design tradeoffs to heart in the DSP56800, their cost-effective 16-bit fixed-point DSP. This 16-bitter has a 16-bit basic instruction word and a16-bit data word. Like the 68K, its basic 16-bit instruction word can be extended with one or two more words to carry immediates, constants, addresses or address offsets. Thus, it has a one-, two-, or three-word instruction. Also like the 68K is it short three-stage pipeline for low latencies.

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.


StarCore Architecture
Another DSP riff on the 68K ISA theme is the StarCore architecture, a 4th generation VLIW. StarCore designers extended a basic 16-bit instruction word with one or two follow-up words, but went one better. Star-Core is a VLIW that operates on a fetch/execute set of instructions. The set of 16-bit instruction words is also extensible by leading predicate words. One or two of these leading words extend all the basic instruction words in the set, allowing more complex instructions and more register choices in the small basic instruction words.

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.


16-Bits?
As one DSP architect noted, "perhaps the most efficient size for an instruction word is 16-bits—extensible of course." That may be true, and the 68K has made a pretty good case for it. A number of DSPs and RISCs (MIPS-16 and ARM Thumb) have taken that approach to minimize code densities and up efficiencies. Looks like those 68K guys were onto a good thing.

Loading comments...

Most Commented

  • Currently no items

Parts Search Datasheets.com

KNOWLEDGE CENTER