Question 1 of 6

Question 1 (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) 512K-word (2¹⁹-word), word-addressable space; a 64-bit instruction format OP(7)|Destination(19)|Source(19)|nextPC(19); 127 of the 128 possible 7-bit opcodes already assigned; the new design must decode all 127 first-implementation instructions unchanged AND still use 64 bits/instruction. (b) 5 instructions, 32-bit (4-byte) encoding each, 2 of the 5 are memory reads of 4 bytes each. (c) polling as an I/O-communication technique.

Find. (a) whether more instructions can be added at all; whether exactly one more can be added; whether 10 more can be added; whether new instructions can use registers. (b) minimum bytes read from memory to run the program once. (c) the pros and cons of polling versus the alternative (interrupt-driven I/O).

Approach. (a) count the spare opcode slots directly from the 7-bit field, then reason about a two-level (escape-opcode) scheme for growth beyond that count. (b) separate instruction-fetch traffic from data-read traffic and sum only what is actually read. (c) weigh the CPU cost of periodic polling against the responsiveness/CPU-cost tradeoff of interrupts.

1. Part (a) — growing the opcode space under backward compatibility. The opcode field is 7 bits wide, so it can distinguish $2^7=128$ codes; the first implementation used 127 of them, leaving exactly $128-127=1$ code point unused. Can more instructions be introduced? Yes. Can it introduce one more? Yes — the single free opcode can be assigned directly to a new instruction, keeping the same Destination(19)|Source(19)|nextPC(19) layout, so nothing about the 127 existing decodes changes and the instruction is still exactly 64 bits. How about 10 more? Not with the flat opcode field alone (only one code point is free), but yes with an extended-opcode (escape) scheme: assign that one free 7-bit code as an escape, and let the remaining $64-7=57$ bits of an escape-tagged instruction be reinterpreted freely as a brand-new field layout with its own secondary opcode — e.g. a 4-bit secondary opcode already yields $2^4=16\ge10$ new instructions, comfortably more than 10, all still packed into 64 bits and without touching any of the 127 original decodes (they never carry the escape opcode, so the decoder still routes them exactly as before). Can it introduce instructions that use registers? Yes, via the same escape: because the escape's 57 remaining bits are not constrained to reproduce the 19-bit memory-address operand format, they can instead be divided into a secondary opcode plus a handful of small register-specifier fields (a modest register file needs only a few bits per specifier), something the original flat format has no room for. Yes to all four: exactly one more instruction fits directly in the spare opcode; ten or more (and register-using instructions) require a two-level escape-opcode scheme built on that single spare code, not a widening of the flat 7-bit field.
2. Part (b) — minimum bytes read from memory. All 5 instructions must be fetched regardless of what they do, at 32 bits (4 bytes) each: $$\text{fetch bytes}=5\times4=20\ \text{bytes}$$ Only the 2 memory-read instructions pull additional data from memory (4 bytes each); nothing else in the 5-instruction program is stated to read memory: $$\text{data-read bytes}=2\times4=8\ \text{bytes}$$ $$\boxed{\text{minimum bytes read}=20+8=28\ \text{bytes}}$$
3. Part (c) — polling pros and cons. Polling has the processor repeatedly test a device's status register in a software loop until it signals ready. Pros: it is simple to implement and reason about (no asynchronous control-flow, no interrupt-controller hardware or vector table needed), it is fully deterministic (the exact instruction sequence executed is known in advance, which matters for tight real-time loops), and for a device that is ALWAYS ready when checked (or checked immediately before use) it avoids the fixed overhead of an interrupt (context save/restore, vector dispatch). Cons: the CPU is busy-waiting rather than doing useful work while the device is not ready, wasting cycles that scale with how often and how long it must poll; responsiveness is bounded by the polling interval, so an infrequent or unpredictable event (a keystroke, an incoming network packet) is either detected late (long interval) or wastes enormous CPU time (short interval); and polling does not scale to many devices, since the CPU must sequentially test each one instead of being notified only when something actually needs attention. Polling trades simplicity and determinism for wasted CPU cycles and poor responsiveness to rare/unpredictable events — it suits a single, frequently-ready device in a simple system, while interrupt-driven I/O suits infrequent events and many devices.