Skip to content

Elias Olofsson - oloeli-3 - Peer-review

Nice work with the lab! The output prints like it should, however I have found some errors according to the lab requirements.

Lab requirements from review assignment in Canvas

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

    The kernel instruction bne $v0, 0x102, return_to_user on line 139 has compiled into two instructions, beginning at address 0x8000009c, because bne takes a register and not an immediate value. The compiler has chosen $at as a register to store 0x102 in before using it in the branch instruction, causing the kernel code to modify other registers than $k0 and $k1.

    The purpose of the $at register appear to be for the compiler to use in order to break up psudo-instructions like this one. But my guess is that even this register is dangerous to modify in kernel code, in case an instruction in user code also gets broken up using $at and the kernel gets invoked in the middle of the two generated instructions.

  2. OK - Check that any other exception/interrupt besides "SYSCALL", ends up in the infinite "kernel_loop". (You can test this by inserting code that generates an "overflow" in proc1.)

    Your overflow exception test does not work, however I have written one that works on my end and the processor gets stuck in the infinite kernel_loop like it should, so your kernel implementation to handle this exception is correct.

    Remember that overflow exceptions are only triggered when the addition is incorrect when the binary values are interpreted as signed. A binary value of all ones is interpreted as -1 in signed two's complement, and adding 1 to this would wrap around to 0, which is mathematically correct triggering no overflow.

    Important

    You need the new version of SyncRim recently posted in the syncrim channel in the course Discord server in order for overflow exceptions to work. In case you haven't already installed it.

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

    I've checked with both mfc0 $xx, $12 instructions and the text on the co-processor in the graphical view that the status register has the value 0x00000003 (two lowest bits 1) while executing user code, and 0x0000000c (two lowest bits 0) while executing kernel code. Just like it should.

Edited by Elias Olofsson