Skip to content

Elias Olofsson - oloeli-3 - Peer-review

Unfortunate bug you've ended up with! Just moving one instruction up by one is enough to fix it, but it was really hard to find! More details within the review bullet points.

Lab requirements from review assignment in Canvas

    • Make sure the repo structure follows the original lab, and that program compiles and works as intended (the correct output sequence is observed in the "Output Window".

    After a day of debugging, I've found the cause of your output bug and it turns out it's one that I've unknowingly made myself.

    When restoring the registers of the PCB you are about to switch to, you start using the restored $sp without accounting for the load delay of one instruction. I did the same error without knowing because I happened to restore an unused register in the load delay slot and therefore didn't notice any error.

    The delay slot when loading $sp has now been filled before starting to use it and the output sequence is correct as a result.

    • Check that the kernel code will preserve all registers but $k0 and $k1 (which are reserved for the kernel).

    You're only storing and restoring the registers that you yourself are using in your user code, while the assignment calls for

    - save the contents of the registers $ra, $fp, $sX, $tX, $aX, $vX and $at on the own stack of the process.

    at point 4 in the "Assignment" section of the README.md. This is because the assignment is about implementing the context switching functionality of an operating system, where the kernel code should be unaware of what registers the user processes happen to use, and therefore store and restore all of them.

    As a side note: be careful about using pseudo-instructions in kernel code as instructions that gets compiled down to multiple instructions might end up using the $at register, like the instruction sw $k0,curpcb on line 259. In this case it doesn't matter as the $at register of the various processes will be preserved and restored if you fix this point.

    All required registers according to the assignment are now stored and restored.

    • Check that any other exception/interrupt besides SYSCALL and ExtInt ends up in the infinite kernel_loop.

    I've tested that typing in the output window and causing an overflow results in the processor getting stuck in the infinite kernel_loop.

    • Check that the two lowest bits of the STATUS REGISTER is "user mode" and "interrupt enabled", when the user program (proc1, proc2, proc3) is executing (also after the return of any SYSCALL).

    I've checked with the text on the co-processor in the graphical view that the status register has the value 0x00000c03 (two lowest bits 1) while executing user code, and 0x00000c0c (two lowest bits 0) while executing kernel code, just like it should. This is because you're calling rfe on every return from kernel code.

Omitting requirements that will be fixed if the unchecked requirements are fixed.

Edited by Elias Olofsson