> Finding the time to properly conceptualise and deeply think about what I’m trying to learn has been challenging This reminds me of something that happened to

> Finding the time to properly conceptualise and deeply think about what I’m trying to learn has been challenging This reminds me of something that happened to me 20 years ago, and cemented my view that teaching should be bottom-up: waiting for our computer architecture lecturer to arrive for the day's lecture -- Interrupts -- I quipped to a friend "I hope he doesn't just walk in and say 'There's something called interrupts'". In a comedic bit of prophecy, the lecturer just then walks in, walks over to the board and says, "There's something called interrupts". Today, if I were him, I would never start by defining the solution. I wouldn't even name it at first. I would first state the problem: we know that a traditional CPU can process only one instruction at a time. And last time we learned that it looks at the program counter at the end of each instruction to see what instruction needs to be executed next. Now if the CPU keeps breathlessly executing the instructions from memory, it's never going to have time to check if I/O devices have any data. How do we solve this problem? A good student will start by suggesting that we have the program poll the I/O devices regularly. Then someone will likely mention the overhead of repeated polling, especially when when there are no inputs most of the time. This should eventually lead to the idea that the CPU itself (rather than the program) should check some sort of input signal between the execution of every instruction. An I/O device would set this input to an active state when it has input for the CPU, and the CPU will catch it immediately after the current instruction. Now at that point, there is no way to tell the CPU which set of instructions to run in response. Instead, we'll have to store those instructions in some specific location that is known to the CPU. Now what do you call this scheme? Interrupts.