Microprocessor Design/Code Density

From Wikibooks, open books for an open world
Jump to navigation Jump to search

In early computers, program memory was expensive. Programmers spent a lot of time minimizing the size of a program to fit it into the limited memory available. Thus the combined size of all the instructions needed to perform a particular task, the code density, was an important characteristic of any instruction set.[1][2] Even today, it makes a large difference whether or not the vast majority of instructions executed fit into the instruction cache, which is by many orders of magnitude smaller than main memory.

Some writers use "byte efficiency", "code efficiency", "operation length reduction", etc. to refer to more-or-less the same concept as code density.[3]

In the early decades of CPU development, people gradually added more and more "powerful" instructions to the instruction set, reducing the total number of instructions stored to implement common tasks, but increasing the average number of bits required to store each instruction -- in many cases this improves overall code density. After the development of on-chip instruction cache, the RISC revolution was led by people who sacrificed code density and eliminated complex, "powerful" instructions in order to simplify and speed up CPU implementation and improve performance on other CPU performance metrics. More recently, some people have been experimenting with minimal instruction set computers (MISC), making the number of bits per instruction much shorter, in an attempt to improve code density.

For processors with variable-length instructions, it helps code density if frequently-used instructions are short, even if that forces other (rarely-used) instructions to be long.

For processors with fixed-width instructions, choosing 16-bit-wide instructions appears to give slightly better code density than 8-bit or 32-bit-wide instructions.[4]

There is a widespread belief that 32-bit microcontrollers have much bigger code size (worse code density) than 8-bit microcontrollers. However, in many cases 32-bit microcontrollers that use mostly 16-bit-wide instructions have smaller code size (better code density) than 8-bit microcontrollers that use mostly 14-bit-wide instructions or 16-bit microcontrollers that use mostly 16-bit-wide instructions.[5][6]


As typical RAM sizes increased, and after the development of the separate instruction cache large enough to contain inner loops and common subroutines (so code density had much less effect on CPU performance metrics),[2] and after the invention of nested subroutines and threaded code and other instruction-set-independent executable compression techniques,[7] code density has become a less important part of instruction set architecture.


Clipboard

To do:
say a few words about ARM Thumb instructions here



Clipboard

To do:
say a few words about the EEMBC CoreMark code size benchmark here



Clipboard

To do:
say a few words about the GCC Code-Size Benchmark Environment (CsiBE) here


Many instruction sets were specifically designed to have high code density.[8][9][10][11][12][13][14][15]

References[edit | edit source]

  1. Wikipedia: code density
  2. a b Margarita Esponda and Ra'ul Rojas. "The RISC Concept - A Survey of Implementations". Section 2: "The confusion around the RISC concept".
  3. Terry Ritter and Joel Boney. "The BYTE 6809 Articles (Jan–February 1979)".
  4. "It seems that the 16-bit ISA hits somehow the "sweet spot" for the best code density, perhaps because the addresses are also 16-bit wide and are handled in a single instruction. In contrast, 8-bitters need multiple instructions to handle 16-bit addresses." -- "Insects of the computer world" by Miro Samek 2009.
  5. Joseph Yiu, Andrew Frame. DRAFT "32-Bit Microcontroller Code Size Analysis".
  6. "Code Density of LCP11xx".
  7. Data Compression/Executable Compression
  8. "AVR Microcontrollers for High-Performance and Power-Efficient 8-bit Processing". quote: "... the AVR instruction set and CPU design are tuned for minimum code size and maximum execution speed. This ... ... high code density... and low power consumption ... still leads the industry."
  9. Wikipedia: AVR32. quote: "Just like the AVR 8-bit microcontroller architecture, the AVR32 was designed for extremely efficient code density and performance per clock cycle."
  10. "AVR32 Architecture Document". quote: "In order to achieve high code density, the instruction format is flexible, providing both compact instructions with 16 bits length and extended 32-bit instructions. ... Compact and extended instructions can be freely mixed in the instruction stream."
  11. "Get Better Code Density than 8/16 bit MCUs: NXP LPC1100 Cortex M0". (see p. 17) ... also mentions "CoreMark" code size benchmark.
  12. "Differences between 680x0 family and ColdFire". quote: "standard RISC processors such as the PowerPC achieve high performance at the expense of low code density, in part because all instructions are the same width (generally 4 bytes) and also because ... ... The ColdFire architecture -- which Freescale Semiconductor characterizes as "Variable-Length RISC" -- aims to share many of the speed advantages of RISC, without losing too much of the code density advantages of the 680x0 family. Like most modern processor architectures, it is optimized for code written in C or C++ ... In order to regularize the instruction stream, all ColdFire instructions are either 2, 4 or 6 bytes wide; ..."
  13. "Brand new 32-bit RISC core: XAP3 ASIC processor liberates embedded systems industry with very high code density, low power and software flexibility" quote: "XAP3 ... achieves a remarkable code density, which Cambridge Consultants estimates could yield as much as a 30% saving in memory usage."
  14. "32-Bit RISC Core - comes with royalty-free licence". quote: "XAP3 ... achieves a remarkable code density, which Cambridge Consultants estimates could yield as much as a 30% saving in memory usage."
  15. "ChipX Introduces Synthesizable 32-Bit CPU With Best-in-Class Code Density for Embedded and Consumer Applications". 2008.