|
|
|
|
|
|
|
1. The baseline load/store architecture. Here, it is assumed that the load/store architecture supports byte-at-a-time character string movement through registers and supports decimal on a digit-by-digit basis, again through movement of operands through registers. |
|
|
|
|
|
|
|
|
2. The general register-memory architectures. Here, R/M (as well as R+M) generally includes memory-to-memory operations (e.g., on IBM mainframes) in support of commercial data types. Thus, for this class of application, the register/memory and the register plus memory architectures are the same. |
|
|
|
|
|
|
|
|
In the following data, we generalized the published statistical information. Since the variance across some of the data is high, we have simplified the data groups and conservatively estimated the expected value of key aspects of the data. For example, as a generalization we might lump together a variety of instructions that all have similar execution properties and similar expected timing, such as ALU-based operations including shift, compare, and logical operations. In distinguishing among various types of operands, if floating-point data indicate an occurrence of 8085% floating-point adds, with the bulk of the remainder being floating-point multiply, we use 80% distribution of adds. Since floating-point multiplies are a more difficult (and slower) operation than adds, a larger number of multiplies provides a more conservative performance estimate. The data is from a combination of sources on a variety of different architectures, adjusted for these differences. Where alternate data are available, the statistics are based upon the best compiler and global register allocator technology available at the time of this writing. As the compiler art advances, we expect an evolution of statistical data towards distributions representing increasing levels of compiler optimization. |
|
|
|
|
|
|
|
|
Since the variance is large, the designer must use caution lest the resultant design become too sensitive to a particular aspect of program behavior. These data should be used only as a starting point for a designfurther analysis including simulations should be done for the final selection and fine-tuning of the design. |
|
|
|
|
|
|
|
|
The L/S architecture continues to evolve. Our baseline L/S corresponds to a simple architecture with an instruction vocabulary of perhaps 100 instructions, including minimum support (byte LD/ST) for character string operations. The various L/S approaches in the marketplace have been changing in several ways in recent years: |
|
|
|
|
|
|
|
|
1. Increased size of instruction vocabulary. |
|
|
|
|
|
|
|
|
2. Increased sophistication of compiler technology. |
|
|
|
|
|
|
|
|
The first trend should, in time (at least for some L/S architectures), minimize the difference in the commercial environment between the L/S and the R/M approaches. |
|
|
|
|
|
|
|
|
The second trend should allow L/S processors to more effectively use their 32 registers (see Figure 2.51). Over the next few years, we expect the difference in dynamic instruction count to largely disappear. The optimized |
|
|
|
|
|