|
|
|
| Table 3.6 Expected Gibson classification profile for transactions processing and systems applications by architecture. Expected instructions executed per 100 HLL operations. | | Systems | | | | | | Move (integer, floating point) | | | | | | | 3.17 | | Branch | | | | | | | 3.10 | | Fixed Point | | | | | | | 3.14 | | Shift, Compare, Logical (word) | | | | | | | | | | | | | | | |
|
|
|
|
|
|
code size of more than three times. We expect that as L/S machines achieve significant impact in this commercial environment, the distribution shown in Table 3.5 will be significantly different, presumably somewhat reducing the overall dynamic instruction count and difference between these architectures. As L/S processors move into the commercial arena, they are being extended to include the supporting data types and operations required by such programs. This has the effect of significantly diminishing the difference, making it somewhat more akin to the differences cited in Table 3.3. |
|
|
|
|
|
|
|
|
Tables 3.33.6 are referenced to the HLL measures mentioned in Chapter 2. For 100 HLL operations executed, we expect the L/S-type architecture to require 200 instructions to be executed, the R/M to require 180 instructions, and the R+M to require 120 instructions to be executed. This assumes optimized compilation and full floating point support across all architectures. The reason for the difference between instruction counts for R/M and L/S is that the R/M architecture possesses a format the L/S does not. It allows the R/M format, which combines two L/S instructions: |
|
|
|
 |
|
|
|
|
LD.W R2, ADDR
ADD.W R1, R1, R2 |
|
|
|
|
|
|
|
|
into a single instruction: |
|
|
|
|
|
|
|
|
ADD.W R1, ADDR. |
|
|
|
|
|
|
|
|
The R+M-type machine takes this one step further by allowing all memory formats, as illustrated next. |
|
|
|
|
|
|
|
|
Suppose we have the isolated statement: |
|
|
|
|
|
|
|
|
In the L/S architecture, we would have: |
|
|
|
|
|
|
|
|
LD.W R1, B
LD.W R2, C
ADD.W R3, R2, R1
ST.W A, R3, |
|
|
|
|
|