3 ms·

The reason I didn't implement interrupts is that I couldn't understand how to do it. It would be better with interrupts, but only by a little bit. The times I

The reason I didn't implement interrupts is that I couldn't understand how to do it. It would be better with interrupts, but only by a little bit. The times I really feel the lack of interrupts are: - the text editor sometimes takes a long time to redraw the screen after reading input, and can drop characters if you type too fast because it isn't ready to poll for another character yet - if a program is stuck in an infinite loop and not doing any system calls, you can't kill it with ^C because the kernel never gets to find out that you typed ^C Those problems would go away if the arrival of a character on the serial port triggered an interrupt which caused the kernel to grab the character from the UART and stick it in a buffer, but I'm not sure the increase in hardware complexity is worth it.

R0b0t1 5y ago
It's worth it. I played with Propeller chips a while back. They have multiple cores and a shared memory but no interrupts. They can work, but you dedicate an entire CPU (expensive!) to a task, usually. The scant times you don't need to is because you poured time into a more difficult cooperative multitasking solution that isn't flexible. You don't need to implement a nested vectored interrupt controller. Even just a timer/counter with overflow interrupt would solve your current issues with lockup by allowing you to implement preemptive multitasking. Once you do that it would be easy-ish to extend to the serial controller. Basically, on interrupt flag = 1, 1. Disable further interrupts (no nesting). This makes things easier to implement. 2. Save register state. For speed a special set of shadow registers can be used, or you can put register state on the stack. 3. Jump to interrupt routine code start. 4. Let interrupt handler run, clear interrupt flag, then return. In the simplest case an input flag simply causes a CALL (push pc, jump to address). In that case the interrupt handler needs to know to save state. You can test flags between instructions to see if you need to inject the push/jump.

R0b0t1 5y ago

It's worth it. I played with Propeller chips a while back. They have multiple cores and a shared memory but no interrupts. They can work, but you dedicate an entire CPU (expensive!) to a task, usually. The scant times you don't need to is because you poured time into a more difficult cooperative multitasking solution that isn't flexible. You don't need to implement a nested vectored interrupt controller. Even just a timer/counter with overflow interrupt would solve your current issues with lockup by allowing you to implement preemptive multitasking. Once you do that it would be easy-ish to extend to the serial controller. Basically, on interrupt flag = 1, 1. Disable further interrupts (no nesting). This makes things easier to implement. 2. Save register state. For speed a special set of shadow registers can be used, or you can put register state on the stack. 3. Jump to interrupt routine code start. 4. Let interrupt handler run, clear interrupt flag, then return. In the simplest case an input flag simply causes a CALL (push pc, jump to address). In that case the interrupt handler needs to know to save state. You can test flags between instructions to see if you need to inject the push/jump.