| OCR Text |
Show 15 should be analyzed (see strategies C and D, below). The timing estimates generated by strategy A are only valid for a particular HLL compiler (i.e ., the estimates implicitly assume that a HLL primitive always compiles to the same machine code). The same compiler with a different object code optimizer must have a new timing model developed that reflects the performance of the optimized code. Several ''software performance systems" or "performance profilers" using performance models similar to strategy A have been reported [3, 6, 12]. These designefS of these systems are concerned primarily with software development environments and the focus is on software performance rather than hardware performance. The accuracy of the timing model is sufficient for tuning software performance, but would be difficult (if not impossible) to use for tuning a machine architecture. The main advantages of strategy A are ease of implementation and low simulation overhead. 2.2 Strategy B The steps for strategy B are (see Figure 2): 1. The HLL program is compiled into the assembler or machine language of the target processor. 2. The assembly language code is analyzed. 3. Timing probes are inserted into the assembly code. 4. The resulting program is converted to the assembly language of the host, assembled, loaded, and executed. In strategy B the timing probes are assembly language statements that increment the simulated clock in fashion similar to the HLL timing probes of strategy A. A simple implementation (for a simple processor) would insert a clock increment for each target machine instruction. However, the number of probes necessary to instrument the program can be reduced (and simulation efficiency increased) by control flow analysis of the assembly language program. |
