Hardware Reference
In-Depth Information
Fallacy There Is Such A Thing As A Typical Program.
Many people would like to believe that there is a single “typical” program that could be used
to design an optimal instruction set. For example, see the synthetic benchmarks discussed in
Chapter 1 . The data in this appendix clearly show that programs can vary significantly in how
they use an instruction set. For example, Figure A.29 shows the mix of data transfer sizes for
four of the SPEC2000 programs: It would be hard to say what is typical from these four pro-
grams. The variations are even larger on an instruction set that supports a class of applications,
such as decimal instructions, that are unused by other applications.
FIGURE A.29 Data reference size of four programs from SPEC2000 . Although you can
calculate an average size, it would be hard to claim the average is typical of programs.
Pitfall Innovating At The Instruction Set Architecture To Reduce Code Size Without
Accounting For The Compiler.
Figure A.30 shows the relative code sizes for four compilers for the MIPS instruction set.
Whereas architects struggle to reduce code size by 30% to 40%, different compiler strategies
can change code size by much larger factors. Similar to performance optimization techniques,
the architect should start with the tightest code the compilers can produce before proposing
hardware innovations to save space.
 
Search WWH ::




Custom Search