Abstract:
A method of providing a programmer with a visualization of power usage. The method is especially suitable for integration within a debugging process (FIG.  20 ). A windows-type display ( 160, 170, 180, 190 ) displays sections of computer code ( 160   a   , 170   a ), as well as numerical values representing power usage ( 160   b   , 170   b ). Next to each section of code, some sort of visual representation of power usage is displayed, such as a bar of a bar graph ( 160   c   , 170   c ). Alternatively, the code can be highlighted if power usage exceeds a given threshold, or comments can be provided next to the code for optimizing power usage.

Description:
This application claims priority under 35 USC §119(e)(1) of Provisional Application No. 60/115,500, filed Jan. 11, 1999. 
    
    
     TECHNICAL FIELD OF THE INVENTION 
     This invention relates to debugger and dis-assembly methods, and more particularly to tools directed to providing programming that reduces the power consumption of a processor. 
     BACKGROUND OF THE INVENTION 
     Power efficiency for processor-based equipment is becoming increasingly important as people are becoming more attuned to energy conservation issues. Specific considerations are the reduction of thermal effects and operating costs. Also, apart from energy conservation, power efficiency is a concern for battery-operated processor-based equipment, where it is desired to minimize battery size so that the equipment can be made small and lightweight. The “processor-based equipment” can be either equipment designed especially for general computing or equipment having an embedded processor. 
     From the standpoint of processor design, a number of techniques have been used to reduce power usage. These techniques can be grouped as two basic strategies. First, the processor&#39;s circuitry can be designed to use less power. Second, the processor can be designed in a manner that permits power usage to be managed. 
     On the other hand, given a particular processor design, its programming can be optimized for reduced power consumption. Thus, from a programmer&#39;s standpoint, there is often more than one way to program a processor to perform the same function. For example, algorithms written in high level programming languages can be optimized for efficiency in terms of time and power. Until recently, at the assembly language level, most optimization techniques have been primarily focussed on speed of execution without particular regard to power use. 
     The programmer&#39;s task of providing power efficient code can be performed manually or with the aid of an automated code analysis tool. Such a tool might analyze a given program so to provide the programmer with information about its power usage information. Other such tools might actually assist the programmer in generating optimized code. 
     U.S. Pat. No. 5,557,557, to Franz, et al., entitled “Processor Power Profiler”, assigned to Texas Instruments Incorporated, describes a method of modeling power usage during program execution. A power profiler program analyzes the program and provides the programmer with information about energy consumption. A power profiler is also described in U.S. Pat. No. 6,125,334, to L. Hurd, entitled “Module-Configurable, Full-Chip Power Profiler”, assigned to Texas Instruments Incorporated. 
     SUMMARY OF THE INVENTION 
     One aspect of the invention is a computer-implemented method of providing a visualization of power usage of a computer program. The method is especially suited for use as part of a debugging process, for use by a computer programmer. First, a determination is made of power usage per processor cycle as the code executes. This determination may be made by receiving values from a power measurement process, from some sort of modeling or estimation process, or from some other means of determining power usage. The section of computer code corresponding to each cycle is displayed. Also, power usage per cycle is displayed as a graph, such that each section of code is displayed with a corresponding graphical measure of power usage. 
     An advantage of the invention is that it provides a programmer with a visualization of cycle-by-cycle power dissipation. Power usage values and graphical representations are displayed together with corresponding sections of code, so that the programmer can easily access the code to make modifications to reduce power dissipation. 
    
    
     BRIEF DESCRIPTION OF THE DRAWINGS 
     FIG. 1 is a block diagram of a VLIW DSP processor. 
     FIG. 2 illustrates the basic format of a fetch packet used by the processor of FIG.  1 . 
     FIG. 3 illustrates an example of the fetch packet of FIG.  2 . 
     FIG. 4A illustrates the mapping of the instruction types for the processor of FIG. 1 to the functional units in its datapaths. 
     FIG. 4B is a table describing the mnemonics of FIG.  4 A. 
     FIG. 5 illustrates a fetch packet having multiple execute packets. 
     FIG. 6 illustrates a code optimization process in accordance with the invention. 
     FIGS. 7A and 7B illustrate an example of unoptimized code together with the corresponding optimized code, respectively, where the optimization has been performed in accordance with Step  63  of FIG.  6 . 
     FIGS. 8A and 8B illustrate an example of unoptimized code together with the corresponding optimized code, respectively, where the optimization has been performed in accordance with Step  63  of FIG.  6 . 
     FIGS. 9A and 9B illustrate an example of unoptimized code together with the corresponding optimized code, respectively, where the optimization has been performed in accordance with Step  63  of FIG.  6 . 
     FIGS. 10A and 10B illustrate an example of unoptimized code together with the corresponding optimized code, respectively, where the optimization has been performed in accordance with Step  64  of FIG.  6 . 
     FIGS. 11A and 11B illustrate an example of unoptimized code together with the corresponding optimized code, respectively, where the optimization has been performed in accordance with Step  65  of FIG.  6 . 
     FIGS. 12A and 12B illustrate an example of unoptimized code together with the corresponding optimized code, respectively, where the optimization has been performed in accordance with Step  65  of FIG.  6 . 
     FIGS. 13A and 13B illustrate an example of unoptimized code together with the corresponding optimized code, respectively, where the optimization has been performed in accordance with Step  67  of FIG.  6 . 
     FIGS. 14A and 14B illustrate an example of unoptimized code together with the corresponding optimized code, respectively, where the optimization has been performed in accordance with Step  68  of FIG.  6 . 
     FIGS. 15A and 15B illustrate an example of unoptimized code together with the corresponding optimized code, respectively, where the optimization has been performed in accordance with Step  68  of FIG.  6 . 
     FIG. 16 illustrates a debugger display having a power usage indicator window in accordance with the invention. 
     FIG. 17 illustrates a display of average current consumption per cycle. 
     FIG. 18 illustrates a display of change in average current per cycle. 
     FIG. 19 illustrates a display of suggested code modifications for power optimization. 
     FIG. 20 illustrates a power optimization visualization system in accordance with the invention. 
    
    
     DETAILED DESCRIPTION OF THE INVENTION 
     The invention described herein is directed to power management for microprocessors. An underlying principle of operation is that the programming provided to the processor can be optimized so as to reduce power usage. Given a particular instruction set, a program using these instructions can be analyzed to detect the presence of non-optimal instruction sequences. These sequences can be modified so that power usage is more efficient, without adversely affecting code functionality. 
     The method of the invention is most useful with VLIW (very long instruction word) processors, which are characterized by their ability to execute multiple instructions in parallel using different functional units within the processor. The invention is also useful with “dual datapath” processors, which execute two instructions in parallel on two datapaths. Both types of processors execute “multiple-instruction words” in parallel in more than one functional unit. However, parallelism is not a limitation of the invention, and any processor that fetches and decodes more than one instruction at a time will benefit from the optimization process. As explained below, for such processors, cycle-to-cycle instruction fetching, decoding, and dispatching can be optimized for power if the code is arranged properly. 
     In light of the preceding paragraph, the term “processor” as used herein may include various types of micro controllers and digital signal processors (DSPs). To this end, the following description is in terms of DSPs—the TMS320 family of DSPs and the TMS320C6x DSP in particular. However, this selection of a particular processor is for purposes of description and example only. 
     Processor Overview 
     FIG. 1 is a block diagram of a DSP processor  10 . As explained below, processor  10  has a VLIW architecture, and fetches multiple-instruction words (as “fetch packets”) to be executed in parallel (as “execute packets”) during a single CPU clock cycle. In the example of this description, processor  10  operates at a 5 nanosecond CPU cycle time and executes up to eight instructions every cycle. 
     Processor  10  has a CPU core  11 , which has a program fetch unit  11   a,  and instruction dispatch and decode units  11   b  and  11   c,  respectively. To execute the decoded instructions, processor  10  has two datapaths  11   d  and  11   e.    
     Instruction decode unit  11   c  delivers execute packets having up to eight instructions to the datapath units  11   d  and  11   e  every clock cycle. Datapaths  11   d  and  11   e  each include 16 general-purpose registers. Datapaths  11   d  and  11   e  each also include four functional units (L, S, M, and D), which are connected to the general-purpose registers. Thus, processor  10  has eight functional units, each of which may execute one of the instructions in an execute packet. Each functional unit has a set of instruction types that it is capable of executing. 
     The control registers  11   f  provide the means to configure and control various processor operations. The control logic unit  11   g  has logic for control, test, emulation, and interrupt functions. 
     Processor  10  also comprises program memory  12 , data memory  13 , tot and timer  14 . Its peripheral circuitry includes a direct memory access (DMA) controller  15 , external memory interface  16 , host port  17 , and power down logic  18 . The power down logic  18  can halt CPU activity, peripheral activity, and timer activity to reduce power consumption. These power down modes, as well as features of processor  10  other than the features of the present invention, are described in U.S. Pat. No. 6,125,334, referenced in the Background and incorporated herein by reference. 
     Processor  10  executes RISC-like code, and has an assembly language instruction set. In other words, each of its VLIWs comprises RISC-type instructions. A program written with these instructions is converted to machine code by an assembler. Processor  10  does not use microcode or an internal microcode interpreter, as do some other processors. However, the invention described herein could be applicable regardless of whether RISC-like instructions control the processor or whether instructions are internally interpreted to a lower level. 
     In the example of this description, eight 32-bit instructions are combined to make the VLIW. Thus, in operation, 32-bit instructions are fetched eight at a time from program memory  12 , to make a 256-bit instruction word. The “fetch packet” is comprised of these eight instructions fetched from memory  12 . 
     FIG. 2 illustrates the basic format of the fetch packet  20  used by processor  10 . Each of the eight instructions in fetch packet  20  is placed in a location referred to as a “slot”  21 . Thus, fetch packet  20  has Slots  1 ,  2 , . . .  8 . 
     Processor  10  differs from other VLIW processors in that the entire fetch packet is not necessarily executed in one CPU cycle. All or part of a fetch packet is executed as an “execute packet”. In other words, a fetch packet can be fully parallel, fully serial, or partially serial. In the case of a fully or partially serial fetch packet, where the fetch packet&#39;s instructions require more than one cycle to execute, the next fetch can be postponed. This distinction between fetch packets and execute packets permits every fetch packet to contain eight instructions, without regard to whether they are all to be executed in parallel. 
     For processor  10 , the execution grouping of a fetch packet  20  is specified by a “p-bit”  22  in each instruction. In operation, instruction dispatch unit  11   b  scans the p-bits, and the state of the p-bit of each instruction determines whether the next instruction will be executed in parallel with that instruction. If so, its places the two instructions are in the same execute packet to be executed in the same cycle. 
     FIG. 3 illustrates an example of a fetch packet  20 . Whereas FIG. 2 illustrates the format for the fetch packet  20 , FIG. 3 illustrates an example of instructions that a fetch packet  20  might contain. A fetch packet  20  typically has five to eight instructions, and the fetch packet  20  of FIG. 3 has seven. Each instruction has a number of fields, which ultimately are expressed in bit-level machine code. 
     The ∥ characters signify that an instruction is to execute in parallel with the previous instruction, and is coded as p-bit  22 . As indicated, fetch packet  20  is fully parallel, and may be executed as a single execute packet. 
     The square brackets [ ] signify a conditional instruction, surrounding the identifier of a condition register. Thus, the first instruction in FIG. 3 is conditioned on register A 2  being nonzero. A ! character signifies “not”, so that a condition on A 2  being zero would be expressed as [!A 2 ]. The conditional register field comprises these identifiers. 
     The opfield contains an instruction type from the instruction set of processor  10 . Following the instruction type is the designation of the functional unit that will execute the instruction. As stated above in connection with FIG. 1, each of the two datapaths  11   d  and lie has four functional units. These functional units are L (logical), S (shift), M (multiply), and D (data). The opfield thus has the syntax [instruction type]. [functional unit identifier]. 
     Some instruction types can be performed by only one functional unit and some can be performed by one of a number of them. For example, only the M unit can perform a multiply (MPY). On the other hand, an add (ADD) can be performed by the L, S, or D unit. The correspondence of functional units to instructions is referred to herein as their “mapping”. 
     FIG. 4A is a table illustrating, for processor  10 , the mapping of instruction types to functional units. It is useful for an understanding of the examples set out below in connection with code optimization. FIG. 4B illustrates the description of each mnemonic. 
     The mapping of functional units to instruction types determines which instructions can be executed in parallel, and therefore whether a fetch packet will become more than one execute packet. For example, if only the M unit can perform a multiply (MPY), an execute packet could have two MPY instructions, one to be executed by each of the two datapaths  11   d  and  11   e . In contrast, the L, S, and D units are all capable of executing an add (ADD), thus an execute packet could contain as many as six ADD instructions. 
     Referring again to FIG. 3, the instruction&#39;s operand field follows the opfield. Depending on the instruction type, the operand field may identify one or more source registers, one or more constants, and a destination register. 
     FIG. 5 is an example of code having multiple execute packets per fetch packet  20 . In this example, there are two fetch packets  20 . The first fetch packet  20  is executed in three execute packets, EP 1 , EP 2 , and EP 3 . The second fetch packet  20  is executed in four execute packets, EP 1 , EP 2 , EP 3 , and EP 4 . 
     To generalize the above-described processor architecture, an executable instruction word, i.e., an execute packet, contains up to eight instructions to be executed in parallel during a CPU cycle. Each instruction in an execute packet uses a different one of the functional units (L, D, S or M) of datapaths  11   d  and  11   e.  The instruction mapping determines which instruction types can be duplicated within an execute packet. 
     The use of instruction words in this manner lends itself to unique techniques for power optimization. As explained below, within an instruction word, instructions can be arranged so that, for each slot, changes from cycle to cycle are minimized. 
     Power Optimization Process 
     FIG. 6 illustrates a code optimization process in accordance with the invention. Each step involves a different code optimization technique. Each step could be performed alone as an independent code optimization technique, or in combination with one or more of the other steps. 
     Each of these steps is explained below, together with one or more examples of code optimization in accordance with that step. The code examples are consistent with the architecture of processor  10  as described above in connection with FIGS. 1-5. Specifically, the examples are consistent with a processor  10  that uses fetch packets that may be divided into execute packets, and special considerations for this distinction between fetch packets and execute packets are noted. 
     However, the invention is equally useful for processors whose fetch packets are the same as the execute packets, as well as for processors that do not use “packets” in the conventional sense. The common characteristic of the code to be optimized is that it has “multiple-instruction words”. The term “multiple-instruction word” is used to signify a set of instructions, where the instructions within the set are grouped at some point within the processor for processing (which may include fetching, decoding, dispatching, executing, or some combination of these functions), and where the executing sis by different functional units of the processor. The “multiple-instruction word” may be structured as a fetch packet, or as an execute packet, or it may have a structure different from a conventional packet structure. 
     In general, each optimization technique is ultimately directed to finding and minimizing cycle-to-cycle bit changes in the binary representation of the assembly code. This is achieved without substantially affecting the overall functionality in terms of the number and type of instructions. Because the functionality is substantially the same, the result is less node switching when instructions are fetched from program memory and when they are decoded and dispatched. This in turn, reduces power consumption. Each step of the overall optimization process is directed to finding and minimizing a different category of bit changes. In a general sense, the code is scanned for various syntax features as opposed to functional features. 
     Step  61  of the code optimization process is re-ordering slot assignments within fetch packets. For each fetch packet, the instructions are viewed by slot assignment. It is determined whether instructions within a fetch packet can be re-ordered so that changing of functional units from cycle to cycle is minimized. The effect of Step  61  is a “vertical aligning” of functional unit assignments. 
     FIGS. 7A and 7B illustrate an example of Step  61 . FIG. 7A shows an instruction stream  70  before the optimization of Step  61 . FIG. 7B shows almost the same instruction stream  70 , optimized in accordance with Step  61 . 
     Instruction stream  70  has three fetch packets. As illustrated, in the second fetch packet, the optimization of Step  61  moves an instruction having an ADD.L 1 X opfield to a slot in which there was an ADD.L 1  opfield in the previous fetch packet. The opfield is the same with the addition of an “X” signifying a cross path. In the third fetch packet, Step  61  moves two instructions, one with an opfield ADD.L 1 X and the other with an opfield ADD.L 2 X, to the same slots as instructions having corresponding opfields in the previous two fetch packets. Likewise, Step  61  moves the B (branch) instruction so that the LDW.D 2  instruction may occupy the same slot as the LDW.D 2  instructions of the previous packets. A NOP (no operation) instruction is used as a place holder so that the same slots will have the same instruction type. 
     Step  61  can be applied to fetch packets having more than one execute packet. In this case, the order of the execute packets must be preserved, but slot assignments can be changed within an execute packet. In general, code having a single execute packet per fetch packet, such as the code of FIGS. 7A and 7B, will be optimized to a greater extent than code having multiple execute packets per fetch packet. 
     The above examples are specific to processor  10 , whose instructions have an opfield containing both the instruction type and the functional unit assignment. For other processors, the functional unit assignment may be in a different field. In any event, the optimization of Step  61  is directed to re-ordering instructions within fetch packets so as to align functional unit assignments. This alignment of functional unit assignments reduces the number of bits changing in each slot from one cycle to the next. 
     Step  63 , like Step  61 , aligns functional unit assignments to avoid unnecessary switching between them. However, Step  63  involves providing new functional unit assignments rather than re-ordering existing instructions. 
     Step  63  is based on the fact that there are certain instructions that are executable by more than one type of functional unit. For example, referring again to FIGS. 4A and 4B, processor  10  has certain instructions that can be executed on both the L and S functional units, and some of these can be executed on the D units as well. 
     FIGS. 8A and 8B are examples of unoptimized code and optimized code, respectively, where the optimization has been performed in accordance with Step  63 . As indicated, an instruction stream has three fetch packets, and each fetch packet has an ADD instruction in the same slot. The unoptimized code of FIG. 8A is executable because the ADD instruction can be performed on any of the functional units (D, S, or L). However, switching between them is unnecessary. Thus, in FIG. 8B, the same functional unit (L) is used for all three ADD instructions. 
     FIGS. 9A and 9B are another example of optimization in accordance with Step  63 . This example illustrates optimization of fetch packets having multiple execute packets. In this case, the cycle-to-cycle analysis of functional unit assignments is directed to execute packets. However, the same concept would apply if the execute packets were fetched as fetch packets. 
     The optimization illustrated by FIGS. 9A and 9B is best understood by charting the cycle-by-cycle usage of the functional units. For the code of FIG. 9A, which is the code before optimization, such a chart would be: 
     
       
         
               
               
               
               
               
               
               
               
               
             
           
               
                   
               
               
                 cycle 
                 M1 
                 S1 
                 L1 
                 D1 
                 M2 
                 S2 
                 L2 
                 D2 
               
               
                   
               
             
             
               
                 1 
                   
                 MVK 
                   
                 LDW 
                   
                 MVK 
                   
                 LDW 
               
               
                 2 
                   
                   
                 SUBX 
                   
                   
                 SHL 
                   
                 STW 
               
               
                 3 
                   
                   
                   
                 LDW 
                   
                   
                   
                 LDW 
               
               
                 4 
                   
                 MVK 
                 MV 
                   
                   
                   
                   
                 STW 
               
               
                 5 
                   
                 MVKLH 
                   
                 LDW 
                   
                   
                   
                 LDW 
               
               
                 6 
                 SMPY 
                   
                   
                   
                 SMPY 
                   
                   
                 STW 
               
               
                   
               
             
          
         
       
     
     For the optimized code of FIG. 9B, the chart would be: 
     
       
         
               
               
               
               
               
               
               
               
               
             
           
               
                   
               
               
                 cycle 
                 M1 
                 S1 
                 L1 
                 D1 
                 M2 
                 S2 
                 L2 
                 D2 
               
               
                   
               
             
             
               
                 1 
                   
                   
                 MVK 
                 LDW 
                   
                 MVK 
                   
                 LDW 
               
               
                 2 
                   
                   
                 SUBX 
                   
                   
                 SHL 
                   
                 STW 
               
               
                 3 
                   
                   
                   
                 LDW 
                   
                   
                   
                 LDW 
               
               
                 4 
                   
                   
                 MVK 
                 MV 
                   
                   
                   
                 STW 
               
               
                 5 
                   
                   
                 MVKLH 
                 LDW 
                   
                   
                   
                 LDW 
               
               
                 6 
                 SMPY 
                   
                   
                   
                 SMPY 
                   
                   
                 STW 
               
               
                   
               
             
          
         
       
     
     As in the example of FIGS. 8A and 8B, functional units are re-assigned to avoid unnecessary switching between functional units from cycle to cycle. The optimization results in better alignment of the functional units. 
     Step  64  is directed to instructions having conditional field assignments. A characteristic of processor  10  is that the 3-bit conditional register field is all 0&#39;s for an unconditional instruction. Conditions of registers B 0 , B 1 , and A 1  have only one “1” in the conditional field. On the other hand, conditions of registers B 2  and A 2  have two “1&#39;s”. Thus, to minimize the number of bits changing from unconditional instructions to conditional instructions, registers B 0 , B 1 , and A 1  are preferred. 
     FIGS. 10A and 10B illustrate an example of Step  64 . Comparing the unoptimized code of FIG. 10A to the optimized code of FIG. 10B, in the first cycle, Step  64  exchanges the ADDs on S 2  and D 2 . As a result of this modification, the number of bits changing in the conditional register field and operand field is reduced. Considering only Slots  5  and  6 , in the unoptimized code, the conditional and operand fields are: 
     
       
         
               
               
               
             
           
               
                   
               
               
                 cycle 
                 L2 
                 D2 
               
               
                   
               
             
             
               
                 1 
                 [!B0] . . . 3,B5,B5 
                 [!A1] . . . 1,B5,B5 
               
               
                 2 
                 [!A1] . . . 5,B3,B3 
                 NOP 
               
               
                   
               
             
          
         
       
     
     This results in 15 bit changes: 8 for the L 2  instruction (2+2+2+2) and 7 for the D 2  instruction (2+1+2+2). In the optimized code, Slots  5  and  6 , these fields are: 
     
       
         
               
               
               
             
           
               
                   
               
               
                 cycle 
                 L2 
                 D2 
               
               
                   
               
             
             
               
                 1 
                 [!A1] . . . 1,B5,B5 
                 [!B0] . . . 3,B5,B5 
               
               
                 2 
                 [!A1] . . . 5,B3,B3 
                 NOP 
               
               
                   
               
             
          
         
       
     
     This results in 13 bit changes: 5 for the L 2  instruction (0+1+2+2) and 8 for the D 2  instruction (2+2+2+2). This optimization reduces power usage by instruction dispatch unit  11   b  and instruction decode unit  11   c.    
     Step  65  of the optimization process analyzes the operand field of the instructions. Operands are re-ordered or registers re-assigned, if this would result in a lower number of bits changing in the operand field. As described above in connection with FIG. 3, depending on the instruction type, the operand field will identify various source registers, a destination register, or constants. It is a large field in proportion to the total bit size of the instruction. For example, for processor  10 , the operand field is 15 bits of the 32-bit instructions. Thus, Step  65  can have an important effect on power optimization. 
     FIGS. 11A and 11B are an example of optimization in accordance with Step  65 . In this example, the re-ordering of operands is within an instruction. The unoptimized code of FIG. 11A is optimized in FIG.  11 B. Two fetch packets are shown, with each fetch packet being executed in a single execute cycle. 
     Considering only Slot # 2  for each of the two cycles, the unoptimized code of FIG. 11A is: 
     
       
         
               
               
             
               
               
               
               
             
           
               
                   
               
               
                 cycle 
                 instruction in slot #2 
               
               
                   
               
             
             
               
                   
               
             
          
           
               
                 1 
                 [A2] 
                 ADD .L2 
                 B12,B11,B12 
               
               
                 2 
                   
                 ADD .L2X 
                 A11,B12,B11 
               
               
                   
               
             
          
         
       
     
     The optimized code of FIG. 11B is: 
     
       
         
               
               
             
               
               
               
               
             
           
               
                   
               
               
                 cycle 
                 instruction in slot #2 
               
               
                   
               
             
             
               
                   
               
             
          
           
               
                 1 
                 [A2] 
                 ADD .L2 
                 B11,B12,B12 
               
               
                 2 
                   
                 ADD .L2X 
                 A11,B12,B11 
               
               
                   
               
             
          
         
       
     
     The binary code for 11 is 1011, and the binary code for 12 is 1100. Thus, the re-ordering of the operands in slot # 2  reduces the number of bits changing in the operand field by six. 
     FIGS. 12A and 12B are another example of Step  65 , showing unoptimized code and the corresponding optimized code, respectively. Here, the re-ordering of operands involves a switch between two different instructions. Slots  2  and  8  of three fetch packets are shown. Comparing the fetch packets of the second cycle (FP 2 ) of the unoptimized code of FIG. 12A to the optimized code of FIG. 12B, the SUB instructions on S 2  and L 2  have been switched. This reduces the number of bits changing in the operand fields of Slots  2  and  8 . 
     Step  65  can also be accomplished with an overall assessment of register use. When there is a choice of registers to use in a given instruction, the register that causes the fewest bits to change from the previous or next instruction can be selected. 
     Step  67  is re-arranging NOP (no operation) instructions so as to provide a smoother code profile. More specifically, Step  67  determines whether there are NOPs that can be moved from one fetch packet to another without affecting the functionality of the code. 
     FIGS. 13A and 13B illustrate an example of unoptimized code and the corresponding optimized code, respectively, where the optimization is in accordance with Step  67 . The code has eight fetch packets, FP 1  . . . FP 8 . The shaded slots contain instructions that are not NOP instructions. As illustrated in the example of FIG. 13B, a number of NOP instructions have been moved from one fetch packet to another. Because a NOP instruction is all 0&#39;s, their placement has a significant effect on the number of bits changing from cycle to cycle. 
     Step  68  is adding dummy instructions to reduce the number of times that a slot switches from NOP to a non-NOP instruction back to a NOP instruction. These dummy instructions duplicate most of the previous or upcoming instruction without adversely affecting data integrity. 
     FIGS. 14A and 14B are an example of unoptimized code and the corresponding optimized code, respectively, where the optimization is in accordance with Step  68 . Only a single slot of three fetch packets is shown. FIG. 14A is an example of unoptimized code, having a NOP instruction in Slot  2  in the second cycle. FIG. 14B is the optimized code, where the NOP has been replaced with a dummy MPY instruction. The dummy instruction does not affect the integrity of the data because the result has been placed in a destination register, Bxx, which is an unused register in the code segment. Because the dummy instruction duplicates much of the preceding and following instructions, the internal toggle activity of processor  10  is reduced. Step  68  is most effective for loop code segments. 
     FIGS. 15A and 15B illustrate another example of unoptimized code and the corresponding optimized code, respectively, where the optimization is in accordance with Step  68 . This example is of a code segment within a loop. As in FIG. 14A, in the unoptimized code of FIG. 15A, in Slot  2 , the instructions switch from a non-NOP to a NOP to a non-NOP. In the optimized code of FIG. 15B, the dummy instruction is a false conditional instruction. For false conditional instructions, the transfer of the result from functional unit to destination register is always disabled. A conditional register, B 0 , has been reserved for use with dummy instructions. Before entering the loop, the conditional register is set to some value. In the example of FIGS. 15A and 15B, B 0  is used for the dummy instruction register and is also the loop counter. Because B 0  is non-zero until the final pass of the loop, for all but the final pass, the result of the conditional instruction is not written to A 12 . On the final pass, the result is written to A 12 . However, because A 12  is not written to in the preceding instruction and is not used as a source in the following instruction, data integrity is not affected. In cycle  3 , the instruction writes to A 12 , which was the original function of the code. 
     Typically, the optimal dummy instruction for Step  68  will be a dummy instruction using a false conditional, such as in the example of FIGS. 15A and 15B. However, in some cases, such as when a conditional register is not available, an alternative dummy instruction, such as that of FIGS. 14A and 14B, may be used. As a result of Step  68 , fewer bits change state in the in-coming instruction stream from program memory  12 . Also, fewer nodes change in decode unit  11   c.    
     Step  69  of the optimization process is to analyze address locations of fetch packets in program memory  12 . For sections of code that are executed repeatedly, such as in loops, the number of bits changing on program memory address lines can be minimized. 
     As a simplified example of Step  69 , assume that a first fetch packet of a loop has address . . . 0111 and the next has the address . . . 1000 in program memory  12 . Each time the program memory  12  switches from accessing the first packet to accessing the second packet, four address bits change. If the second packet were moved to address . . . 0110, then only one bit would change. 
     Graphical User Interface for Power Optimization during Debugging 
     Today&#39;s debugger tools provide programmers with an interface that aids them in developing, testing, and refining programs. The debugger may also provide an interface to processor simulators and emulators. A feature of the present invention is the integration within the debugging process, of a process that provides a visualization of power usage during program execution. 
     FIG. 16 is an example of a debugger display  160 . In the example of this description, the debugger display  160  is especially designed for the above-described processor. As illustrated, display  160  follows the conventions of windowing operating systems, such as pull-down menus  161   a,  toolbar icons  161   b,  and a status bar  161   c.    
     Display  160  shows a number of different types of windows, each serving a specific purpose and having unique characteristics. Each window is identified by a name in its upper left hand corner. Code display windows display code, and include a File window  162  that displays source code, Disassembly window  163  that displays the disassembly (assembly language version) of memory contents, and a Calls window  164  that identifies function calls. The Profile window  165  displays statistics about code execution. Data display windows permit observation and modification of various types of data, and include a Memory window  166  that displays the contents of a range of memory, a CPU window  167  that displays register contents, and a Watch window  168  that displays selected data such as variables, specific registers, or memory locations. A Command window  169  provides an area for typing in commands and for displaying various types of messages. 
     As explained below, a feature of the invention is the use of the Profile window  165  to display information about power usage during execution. Alternatively, a new window could be added to display  160 . 
     FIG. 17 illustrates a first example of a screen  170  that might be displayed in Profile window  165 . Screen  170  has a code portion  170   a , a numeric profile portion  170   b,  and a graph portion  170   c.    
     For each clock cycle, the total average power usage is displayed as a bar graph. Each bar of graph portion  170   c  and its corresponding numerical values in portion  170   b  are adjacent to the code executed in that cycle. The numerical value of power usage is also displayed. 
     In the example of FIG. 17, the power usage is in terms of current in milliamps but other measures of power usage could be used. Generally, the power usage (dissipation) is measured in terms of transistor switching. Any instruction can be defined in terms of how many transistors are turned on or off. Other techniques for determining power usage can be used, including various modeling, estimation, or measuring techniques. For purposes of this invention, it is assumed that the debugger process (or stand-alone visualization process) is provided with the appropriate power measurement data. 
     FIG. 18 illustrates a screen  180  that is similar to the screen of FIG. 17, and which might also be displayed in Profile window  165 . Like screen  170 , screen  180  has a code portion  180   a,  a numerical profile portion  180   b,  and a graph portion  180   c.  However, for screen  180 , the graph portion  180   c  portrays the change, from cycle to cycle, in average power usage. 
     FIG. 19 illustrates a screen  190 , which could also be displayed in Profile window  165  or could be a modification of Disassembly window  163 . Screen  190  has a code portion  190   a , a numerical profile portion  190   b , and a suggestion portion  190   c . Suggestion portion  190   c  identifies sections of code that could be optimized to reduce power usage. These suggestions are consistent with the techniques discussed above in connection with FIGS. 6-15. As stated above, a compilation process could be developed to automatically detect code sections amenable to the various types of optimization. 
     In FIG. 19, the numerical profile portion includes an Index value for each packet. This index represents a user-defined threshold, which if exceeded indicates that an attempt should be made to optimize the corresponding code. 
     Another type of graphical usage interface mechanism could be the highlighting of code in Disassembly window  163 . By use of color codes, packets could be highlighted a different color depending on whether its power usage is less than or greater than a given threshold (or range) or was within range. 
     FIG. 20 illustrates the entire power visualization system in accordance with the invention. A target processor  201  executes a computer program. Although the above description is in terms of assembly language for a VLIW processor, the same concepts could be applied to any processor whose cycle to cycle power dissipation can be reduced by modifying its instructions. Likewise, the same concepts can be applied to any computer programming code whose cycle to cycle power usage can be monitored, not just to assembly code. 
     During execution of the computer program on target processor  201 , power measurement process  202  obtains cycle-by-cycle power usage values, which it provides to debug process  203 . Although the above description is in terms of a visualization process that is integrated with a conventional debug process  203 , the same concepts could be used to provide a stand-alone power usage visualization. A separate debug process  203  could then be used to edit the computer program. 
     OTHER EMBODIMENTS 
     Although the present invention has been described in detail, it should be understood that various changes, substitutions, and alterations can be made hereto without departing from the spirit and scope of the invention as defined by the appended claims.