How are the software program instructions in a computer system executed?

1.3.3 Execution Cycle

Program execution is illustrated in Figure 1.7. Assuming that the application program code is in RAM, the program execution cycle proceeds as follows:

The CPU outputs (1) the address of the memory location containing the required instruction (this address is kept in the program counter). The sample address is shown in hexadecimal form (3A24) in Figure 1.7, but it is output in binary form on the address lines from the processor (for an explanation of hex numbering see Appendix A). The address decoder logic uses the address to select the RAM chip that has been allocated to this address. The address bus also connects directly to the RAM chip to select the individual location, giving a two-stage memory location select process.

The instruction code is returned to the CPU from the RAM chip via the data bus (2). The CPU reads the instruction from the data bus into an instruction register. The CPU then decodes and executes the instruction (3). The operands (code to be processed) are fetched (4) from the following locations in RAM via the data bus, in the same way as the instruction.

The instruction execution continues by feeding the operand(s) to the data processing logic (5). Additional data can be fetched from memory (6). The result of the operation is stored in a data register (7), and then, if necessary, in memory (8) for later use. In the meantime, the program counter has been incremented (increased) to the address of the next instruction code. The address of the next instruction is then output and the sequence repeats from step 2.

The operating system, the application program and the user data are stored in different parts of RAM during program execution, and the application program calls up operating system routines as required to read in, process and store the data. PC processors have multi-byte instructions, which are stored in multiple 8-bit locations, and use complex memory management techniques to speed up program execution.

Viewing Memory

While program execution is stopped the debugger can show the contents of RAM. There is no way to view memory while the program is running. The easiest way to check the value of a variable is to hold the mouse cursor over a variable in the source code. The debugger pops up the value in a small window. This is called mouse-over. See Figures 25.3 and 25.4.

The debugger also has a watch panel where you can enter any number of C expressions. Those expressions (usually just a variable name) are evaluated and the values shown in the watch panel. You can change the radix each watch item is shown in (for example hex or decimal).

In addition to the watch panel, the debugger has RAM panel that shows the entire contents of the RAM. The special function registers (SFRs) are included in the RAM view and they are shown by themselves by name in the SFR panel. Finally, you can view the SFRs sorted by peripheral and with annotations as to what the registers mean using the peripherals tab. See Figure 25.5.

Changing the program

While debugging a program, there are many situations when you observe how to fix the issue, or you just want to modify the program execution. GDB provides the possibility to modify on the fly variables, memory, registers, to call functions, return from functions or to modify the program counter while the program is debugged. This may save some time as compared with the standard solution: modify the code, compile it, run the program on the target, reproduce the same error conditions and test the new program’s changes.

Changing the program execution should be done with caution, especially when you directly modify the registers, including the program counter, as it may cause fatal errors in the execution.

The program execution can be changed in the following ways:

Change the value of a local or global variable: assign 11 to variable “i”:

(gdb) set variable i=11

Change the memory: set value 37 to the memory 0xbfc45400, converted to int:

(gdb) set {int}0xbfc45400 = 37

Change the value of a register:

(gdb) set $r0=0×10

Modify the execution address: the program counter is modified. The next run control command (run, continue, step, next) will execute from this new program counter address:

(gdb) set $pc=0×80483a7

(gdb) set $pc=&compute_data

Continue at a different address: resume execution at the specific line or at specific address:

(gdb) jump data.c:19

Continuing at 0×80483a7.

(gdb) jump *0×80483a7

Continuing at 0×80483a7.

Return from a function: cancel the execution of the current function from the current position. If an argument is passed to the command return, it is used as the return value of the function:

(gdb) return 1

Execute a function:

(gdb) call get_next_data(0)

$5 = (struct data_t *) 0×8049600

(gdb) call get_next_data(1)

$6 = (struct data_t *) 0×8049608

Idle Register File DVS

During program execution, RF dissipates two types of static power. First, between the instruction issue stage and commit stage, the register does not store useful values, but waits for instruction commitment, thus waste static energy/power. The second type occurs when a register stores a temporary value which is no longer to be used or may be referenced again but after a long time. In this case, because most consumer instructions nearby the producer have already read out that value from the ROB, it is possible that the register keeps a useless value for a long time without any references. In some cases, the short-lived values even let allocated registers never be referenced once after the instruction issue stage. In Ref. [46], they find that more than 70% values in a program are short lived.

To address mentioned RF inefficiency problem, Shieh and Chen [46] proposed monitoring mechanism in the datapath and ROB to find out which temporary values possibly make registers have more static power. To prevent the first type of mentioned static power components, the mechanism identifies that a register will temporarily become idle after the instruction issue stage. Because the allocated register will not be referenced during instruction execution until the commit stage, the monitoring mechanism has the ability to monitor each register's usage along pipeline stages.

To prevent the second-type static power, identify that a register possibly stores a “seldom-used” temporary value. They added a simple indicator in each ROB entry to monitor, for each temporary value, how many consumer instructions have appeared before commitment. If a temporary value has many consumers appearing before commitment, the probability that this value becomes “seldom-used” after commitment will become very large.

Their monitoring mechanism cooperates with the DVS mechanism. When it identifies that a register is idle, it triggers the DVS mechanism to power down that register's supply voltage to lower voltage levels. If the monitoring mechanism finds that a register will be accessed soon (e.g., at the stage just before instruction reference or commitment), it early alerts the DVS mechanism to power on that register's supply voltage to the normal voltage level. They assumed that each register has three voltage levels: active (1 V), drowsy (0.3 V), and destroy (0 V).

Simulation results show that through ROB monitoring, a RF can save at least 50% static power consumption with almost negligible performance loss.

Summary

•

Interrupts pause program execution in response to some hardware event and cause an interrupt service routine (function) to execute.

Interrupts happen independently (asynchronously) from program execution.

Interrupts return to the point they interrupted when the ISR completes.

Programmers must define an interrupt handler for each interrupt source, enable the interrupt source, and enable global interrupts.

The time spent in an ISR is added to the time the main program takes to execute.

Noise generating multiple interrupts may be accounted for with interrupt handlers.

Extreme care must be taken when multi-byte data is accessed inside and outside an ISR.

Interrupt handling is controlled by an interrupt flag, an interrupt enable bit, and the global interrupt enable bit.

Interrupt handlers are invoked from the interrupt vector. This vector is the link from the hardware interrupt to the firmware handler.

Some PIC®s have additional interrupt features such as a dual priority interrupt, interrupt levels, and interrupt nesting.

Interrupt latency is the time from the hardware signal until the ISR code begins execution.

Exercise 17-1

Objective: Write programs that use interrupts to perform some basic tasks.

Requires: E3 module, USB cable, PC, frequency generator (if available).

1.1 Program Execution

Describe the process of program instruction execution in a PIC MCU by reference to the data sheet. Explain the role of each block, and how the instructions and data are moved around. Use the instructions MOVLW XX, ADDWF XX and CALL XXX as examples to explain the execution sequence. Identify the binary codes that will appear on the internal busses when these instructions are executed. Refer to ‘PIC Microcontrollers (Ed 3)’ if necessary.

1.2 MPLAB8 Test

Download and install the MPLAB8 development system (if available). Enter and save the program LED1 source code in a suitable folder. Assemble (Quickbuild) and run the program in simulation mode. Set the MCU clock to 40kHz and disable the watchdog timer. Display the SFRs and confirm that PCL tracks the execution point and Port B increments from zero. Note the effect on the Z flag when the port register is cleared, then incremented. Use a break point and the stopwatch to measure the loop execution period (600µs).

6.1 Program Timing

Microcontroller (MCU) program execution is driven by a clock signal generated by an internal oscillator, which may be controlled by an external RC circuit or crystal. This signal is divided into four internal clock phases (Q1–Q4) that run at a quarter of the oscillator frequency (Fosc/4). These provide four separate pulses during each instruction cycle, which trigger the processor operations. These include fetching the instruction code from the program memory and copying it to the instruction register. The instruction code is then used by the decoder to set up the control lines to carry out the required process. The four clock phases are used to operate the data gates and latches within the MCU in sequence to complete the data movement and processing (see Microchip's ‘PIC Mid-Range MCU Family Reference Manual’ and Appendix C).

The instruction timing is illustrated in Figure 6.2. Most instructions are executed within these four clock cycles, unless a jump (GOTO or CALL) occurs. These will take eight clock cycles, because the program counter contents have to be replaced, taking an extra instruction cycle. The PIC® chip operates a simple pipelining scheme which overlaps the fetch cycle of one instruction with the execution cycle of the previous one, doubling the speed in linear sequences at the expense of a delay of one instruction cycle when branching. An output instruction clock signal at Fosc/4 is available at the CLKOUT pin to operate external circuits synchronously; it can also be used in hardware testing to check that the clock is running, and to monitor its frequency.

If the clock rate is known, the execution time for a section of code can be predicted. A frequency of 4 MHz, using a crystal oscillator, is a convenient value as it gives an instruction cycle time of 1 μs. This is also the default frequency of the 8 MHz internal oscillator. The NOP (No OPeration) is useful here to adjust the sequence execution time; it can be used to insert a delay of one instruction cycle, that is, four clock cycles.

This point is illustrated in the simulation of program BIN5, Figure 6.2, which is a modification of BIN4 designed to give a binary count output with an output period of exactly 2 ms (500 Hz) at the LSB. A delay of 1 ms overall can be created using a counting loop set to 247 and a NOP in the loop to make the loop execution time 4 μs. The total loop time is then 247 × 4 = 988 μs plus 12 cycles for the loop control, giving a total of exactly 1000 μs. This is displayed on the stopwatch by setting a breakpoint at the start of the loop, and zeroing the stopwatch before running.

Delay Icon

Toolbar

Icon (Figure 6.7).

Figure 6.7.

Flowchart icon (Figure 6.8).

Figure 6.8.

Delay icons are used to slow down program execution and for program timing. They are particularly useful in slowing program execution speed down to allow for human interaction (Figure 6.9).

Figure 6.9.

Display Name is the name labeled for the icon when it appears on the flowchart.

4.1.6 Switch Input Interrupts

In simple programs, or where program execution speed is not important, inputs can be checked regularly within the main loop (polled). However, this generally wastes too much processor time, so interrupts are often used to read the inputs. Say we want the output to operate at the highest possible frequency, but also allow adjustment via input switches; polling the inputs will slow it down. Assigning interrupts to the inputs (using RB4–RB7 in the 16F877A) is the answer.

Interrupts allow external devices or internal events to force a change in the execution sequence of the MCU. When an interrupt occurs in the PIC, the program jumps to address 004 and continues from there until it sees a Return From Interrupt (RETFIE) instruction. It then resumes at the original point, the return address having been stored automatically on the stack as part of the interrupt process.

Typically, a GOTO ISR (Interrupt Service Routine) is placed at the interrupt address 004, and the ISR placed higher up memory. The interrupt source must be identified by the associated flag, e.g. the Timer0 timeout flag. This has an associated interrupt enable bit which allows the MCU to respond to (or ignore) this particular source. A global interrupt enable bit allows all interrupts to be enabled or disabled together; they are disabled by default. If more than one interrupt source is enabled, the program must test, as part of the ISR, the individual interrupt flags to see which is active.

Program 4.3 (VSM project COUNT3) uses the RB0 interrupt, which allows a change on that pin to trigger an interrupt. The test program runs a simple output loop incrementing Port D. When a button connected to RB0 is pressed, an interrupt is called which stores the current output value, switches on all the outputs for about 3 s (using Timer0 with prescale factor of 128) to represent the interrupt in progress and then continues the output from the same value by recovering from storage.

When an interrupt is called, we normally want the interrupted task to be restarted as though the interrupt had never happened. Therefore, the contents of any relevant register must be saved and later restored, particularly the status register and any other status flags. Ideally, each task will be allocated its own set of working data registers, but SFRs used by both tasks must also be saved at the start of the ISI and restored at the end, before the return from interrupt. This is called context saving.

3.2.2 Program Counter, PCL: File Register 02

The program counter keeps track of the program execution by holding the address of the current instruction. It is automatically incremented to point to the next instruction during the execution cycle. If there is a jump in the program, the program counter is modified by the jump instruction (e.g. the last one in this program), so that it then points to the required jump destination address. PCLATH stands for program counter latch high. This stores the most significant two bits of the 10-bit program counter, which also cannot be accessed directly.