|
|
|
|
|
|
|
being the frequency of occurrence of this type of instruction, where the move as a class is 100%. |
|
|
|
|
|
|
|
|
For the scientific environment, the higher occurrence of load and store for the L/S architecture is the result of the lack of a register-to-memory format. This occurs for both general-purpose and floating-point registers. This data does not assume use of interprocedural register allocation, hence the advantage of more registers in L/S (32 vs. 16 in R/M or R+M) is not significant. If interprocedural allocation were used, the additional registers in L/S would then reduce the required number of move instructions. In this case, we estimate that the L/S and R/M counts would be roughly equivalent. We suggest that the designer simply use the R/M data for this situation. |
|
|
|
|
|
|
|
|
The R+M architecture with full memory-to-memory support goes a long way towards eliminating load and store instructions, since floating point and integer operations can be performed on a memory-to-memory basis. Register MOVE instructions simply move values from register to register. They can be used to zero out registers, or to protect a register value from being overwritten. Finally, load and store multiple registers are operations that are often associated with procedure calls. For our data, a load multiple occurs about three times more frequently than a store multiple. However, both are low-frequency operations. Usually the load and store multiple instructions are run-on instructions, Generally, their execution time is closely related to the number of registers transferred. |
|
|
|
|
|
|
|
|
For commercial applications (Table 3.16), we lump the R/M and the R+M architectures. This architectural equivalence is only approximate, as the R/M architecture has some additional integer load and store activity to manage address computations that well-compiled code for an R+M might avoid. A major member of the move class for this environment is memory-to-memory character string move (or move characters, MOVE.C). As mentioned earlier, this table shows an unusually high number of move character instructions for the L/S architecture, since it is assumed that four bytes are moved into a register at a time. Notice that an L/S architecture may use no more execution cycles than the R+M with full support for character moves, depending on how the R+M architecture has been designed. For example, it may treat the occurrence of a MOVE.C as a run-on instruction and allocate one execution cycle per byte to its execution. |
|
|
|
|
|
|
|
|
3.4.6 Register-Based Addressing |
|
|
|
|
|
|
|
|
One of the most important stages in the pipeline is the address generation (AG) stage. In a typical R/M architecture, the result of address generation is the sum of a base register, an index register, and a displacement. Table 3.18 from Peuto and Shustek [231] shows the frequency of use of the address components. |
|
|
|
|
|
|
|
|
In more than 75% of the cases only one register is actually used (usually the base register). |
|
|
|
|
|
|
|
|
Recall that the R/M format has the following components: |
|
|
|
 |
|
|
|
|
OP R1,DISP [RX,RB], |
|
|
|
|
|