Task $3$ Estimating ISR Execution Time $($Preparation $+40\%$ Laboratory$)$ Assembly code is at this time mostly employed in situations, where speed is very important, and very short execution time for the code is critical. This is because the code can be optimised or tuned to execute in as short a time as possible, by careful choices in instructions, and careful design of the algorithm to be used. Instances of code that are commonly written in assembly language are algorithms which are executed at very high frequencies $($number of times per second$),$ in operating systems, embedded code, and code for multimedia libraries or applications. In operating systems, code used in the kernel for context switching and in device drivers, often includes assembly code routines. ISRs, which are usually incorporated in a device driver, are very often written in assembly code. How can we estimate the time it takes for a fragment of assembly code to execute? As you have learned across a number of FIT$3159$ lectures, the execution of an instruction takes place over several machine clock cycles. How many clock cycles depends both on the architecture of the processor core, and how the core has been designed internally. In general, the less work the instruction has to perform on its operands, the fewer clock cycles are required. If more work is performed, more clock cycles are required. Consider a RISC processor that runs at a clock frequency of $1$ GigaHertz. Each clock cycle has a duration of $1$ nanosecond: fcore $=1*109[$Hz$]$; tcycle $=1/$ fcore ; tcycle $=1/1*109=1*10-9[$sec$]=1[$ns$]$; A short instruction such as a copy from register to register might require $1$ clock cycle, and will take $1$ nanosecond to execute. A complex instruction such as an integer multiply between two registers might take $10$ clock cycles, or $10$ nanoseconds to execute. We assume the instruction is in cache, and all instructions are prefetched, so we do not have to count the opcode fetch cycle in the execution time.