The use of registers in a processor reduces the data and instruction memory traffic. Since this reduction is a significant factor in the improvement of the program execution time, recent VLSI processors have a large number of registers which can be used efficiently because of the advances in compiler technology. However, since registers have to be saved/restored across function calls, the corresponding register saving and restoring (RSR) memory traffic can almost eliminate the overall reduction. This traffic has been reduced by compiler optimizations and by providing multiple-window register files. Although these multiple-window architectures produce a large reduction in the RSR traffic, they have several drawbacks which make the single-window file preferable. We consider a combination of hardware support and compiler optimizations to reduce the RSR traffic for a single-window register file, beyond the reductions achieved by compiler optimizations alone. Basically, this hardware keeps track of the registers that are written during execution, so that the number of registers saved is minimized. Moreover, hardware is added so that a register is saved in the activation record of the function that uses it (instead of in the record of the current function); in this way a register is restored only when it is needed, rather than wholesale on procedure return. We present a register saving and restoring policy that makes use of this hardware, discuss its implementation, and evaluate the traffic reduction when the policy is combined with intraprocedural and interprocedural compiler optimizations. We show that, on the average for the four general-purpose programs measured, the RSR traffic is reduced by about 90 percent for a small register file (i.e., 32 registers), which results in an overall data memory traffic reduction of about 15 percent.

To design a new processor or to modify an existing one, designers need to gather data to estimate the influence of specific architecture features on the performance of the proposed machine (PM). To obtain this data, it is necessary to measure on an existing machine (EM) the dynamic behavior of typical programs. Traditionally, simulators have been used to obtain measurements for PMs. Since several hundred EM instructions are required to decode, interpret, and measure each simulated (PM) instruction, the simulation time of typical programs is prohibitively large. Thus, designers tend to simulate only small programs and the results obtained might not be representative of a real system behavior. In this paper we present an alternative tool for collecting architecture measurements: the Block-and-Actions Generator (BKGEN). BKGEN produces a version of the program being measured which is directly executable by the EM. This executable version is obtained directly with the EM compiler or with the PM compiler and a assembly-to-assembly translator. The choice between these alternatives depends on the EM and PM compiler technology and the type of measurements to be obtained. BKGEN also collects the PM events to be measured (called actions). Each EM block of instructions is associated with a PM block of actions so that when the program is executed, it collects the measurements associated with the PM. The main advantage of BKGEN is that the execution time is substantially reduced compared to the execution time of a simulator while collecting similar data. Thus, large typical programs (compilers, assemblers, word processors, ...) can be used by the designer to obtain meaningful measurements.