Question 3 of 6: Minimum Memory Traffic for Program Execution, and Polling vs. Interrupt-Driven I/O

Question 3: Minimum Memory Traffic for Program Execution, and Polling vs. Interrupt-Driven I/O (20 marks)

Question text not reproduced: the examination questions are © Engineers and Geoscientists BC. Open the official past paper (linked at the top of this page) to read the question, then follow the worked solution below.

Given. (a) 4-byte instructions, one unified memory for both instructions and data, 1000 executed instructions, 10% of which are memory-read instructions, each reading 4 bytes. (b) The two simplest CPU–peripheral communication techniques: polling and interrupts.

Find. (a) The minimum total bytes read from memory to execute the program. (b) The pros and cons of polling and of interrupt-driven I/O.

Approach. (a) every executed instruction must first be fetched (4 bytes each) from the single shared memory, and a fraction of them additionally perform a 4-byte data read; summing both traffic components gives the minimum (no re-fetches, no branches re-executing code) byte count. (b) contrast what each technique costs the CPU in wasted cycles versus servicing overhead.

1. Part (a) — minimum bytes read. Every one of the 1000 executed instructions must be fetched from memory once, at 4 bytes each (instruction fetch traffic): $$\text{fetch bytes} = 1000 \times 4 = 4000\text{ bytes}$$ Of those 1000 instructions, 10% ($=100$ instructions) are memory-read instructions that each additionally read 4 bytes of data from the same memory: $$\text{data-read bytes} = (0.10\times1000)\times4 = 100\times4 = 400\text{ bytes}$$ Since there is only one memory serving both instruction fetches and data reads, the minimum total traffic is the sum of the two (this is a lower bound: it assumes no instruction is fetched more than once, e.g. no loop re-execution beyond the given 1000-instruction count): $$\text{total} = 4000 + 400 = \boxed{4400\text{ bytes}}$$
2. Part (b) — polling vs. interrupt-driven I/O. Polling (programmed I/O): the CPU repeatedly reads a device's status register in a tight loop until it signals ready, then transfers the data itself. Pros: simple to implement (no extra hardware, no interrupt controller, no re-entrancy or priority issues to reason about) and has the lowest possible response latency once the CPU is actively watching, since there is no interrupt-dispatch overhead. Cons: the CPU is unavailable for any other work while it busy-waits, which wastes an enormous number of cycles for a slow device (e.g. a keyboard) and scales terribly if many devices must be polled in turn (the polling loop's period grows with the device count, so no device can be serviced promptly). Interrupts: the device signals the CPU asynchronously when it needs service, and the CPU otherwise executes other work. Pros: the CPU is fully available for other tasks between events, and with a priority scheme, urgent devices can preempt less urgent ones — this is essential for a multi-device, general-purpose system. Cons: every interrupt costs a fixed overhead (saving/restoring processor state, vectoring to the interrupt-service routine, returning), which for a high-frequency device can dominate total execution time and, without careful priority/masking design, interrupts can arrive faster than they can be serviced or can disrupt time-critical code via unpredictable latency. Polling trades zero per-event overhead for 100% CPU occupancy while waiting; interrupts trade a fixed per-event servicing cost for freeing the CPU between events — the right choice depends on device speed and event frequency (polling suits a single, fast, always-active device; interrupts suit multiple, intermittent, or slow devices).