This past week has seen slow but steady progress with the protected mode support in DS2x86. After the previous blog post, I started thinking about ways to make the existing real-mode code more compatible with the needs of protected mode, and 32-bit memory access. In the original DSx86 code I had used all the 16-bit registers shifted to high 16 bits, and I used the lowest byte of the currently effective segment (which I kept in r2 register) to tell whether a segment override is in effect. Most of the opcodes need to know whether a segment override is in effect to calculate the correct memory address when using BP-based indexing. While memory access normally defaults to Data Segment (DS), addressing memory with the BP register defaults to Stack Segment (SS). In DSx86 I kept the currently effective segment register in r2 highest 16 bits, with the lowest byte telling whether a segment override is in effect. The SS register value was kept in the high 16 bits of r3 register, with the DS register value in the low 16 bits of the same register. Thus, in the main loop I could easily reset the segment override to be off and r2 register having the default DS register value like this:

ldrb r1,[r12],#1 @ Load opcode byte to r1, increment r12 by 1
mov r2, r3, lsl #16 @ r2 high halfword = logical DS segment, clear segment override flags
ldr pc,[sp, r1, lsl #2] @ Jump to the opcode handler

Can't get much more efficient than that, when trying to perform two logically different operations, making r2 contain the currently effective segment and clearing a segment override flag. The BP-based memory address handling in turn checked whether a segment override is in effect and if not, made the r2 register contain the current SS value with the following code:
.macro mem_handler_bp_destroy_SZflags
tst r2, #0xFF @ Is a segment override in effect? Zero flag will be set if not
biceq r2, r3, #0x0000FF00 @ r2 = logical SS segment in high halfword, with garbage in low byte
.endm

I had used a somewhat similar approach in DS2x86, as it was just copied and translated to MIPS assembly from the DSx86 method. To prepare for protected mode, I wanted to change this method so that the register that keeps the currently effective segment (#defined to be "eff_seg", in reality register ra) directly contains a linear memory address (which in real mode would be the segment value shifted left 4 bits). So, I could not use the same trick of storing the segment override flag in this register. I really did not want to make the code slower than it currently was, so I actually spent two days just thinking how I could change the segment override flag handling so that the main loop would not slow down (my first priority), I would not need to waste a new register for just this flag (second priority), and that the BP register memory access would also be as fast as possible (third priority).

After spending two days thinking about this problem, the solution finally occurred to me. In the end the main loop did not get any slower, I did not need to use a new register, and the BP addressing was just as fast as before! Here is the resulting code, with some explanation following.

lw t1, opcode_table(t1) // Get the opcode handler address from the opcode table
move eff_seg, eff_ds // Set DS to be the effective segment
ori flags, FLAG_SEG_OVERRIDE // Fix the CPU flags, telling we have no segment prefix
jr t1 // Jump to the opcode handler

After assembling, the generated code looks like this:
8006453c: 8d290000 lw t1,0(t1)
80064540: 01e0f821 move ra,t7
80064544: 01200008 jr t1
80064548: 37390002 ori t9,t9,0x2

The MIPS assembler does a lot of changes to the original ASM code behind the scenes, due to the peculiar features of the processor. For example, all jumps and branches have a "branch delay slot" following them, which is actually executed before the branch is taken. The assembler reorders the opcodes so that the jump is moved before the preceding opcode, if the preceding opcode (ori in my example) has no effect on the branch instruction itself (which it does not here). If the jump can not be moved higher, then a NOP operation is added into the branch delay slot, wasting one CPU cycle. Also, as loads from memory (the lw opcode) cause a pipeline stall if the register that is loaded is used in the next opcode, you also lose a CPU cycle if you don't have any useful operations (that do not use the loaded register) to put immediately after the load opcode. Thus, there is no way to make the main loop code faster than what it currently is, so my first priority was fulfilled. I need to have one operation after the branch address loading, and I need to have an operation in the branch delay slot.

I managed to fulfill my second priority by using the x86 CPU flags emulation register (#defined as "flags", being in reality register t9). The x86 flags register has a reserved bit 1 (with value 2) that should always be set. I set this bit in the main loop, and then reset the bit to zero in all segment override handlers. Since