Implement branch prediction

[LiamSkirrow]

By default, I'm not sure what will happen when I implement the branch instructions. But eventually, it would be good to be able to support branch prediction.

However, don't prematurely optimise, this is something that should be implemented after the basic branch instructions are developed and proven to work on their own. As a baseline, the branch instructions should probably just stall until the conditional has been determined or not.

[LiamSkirrow]

Also read up on the differences between branch prediction and branch target prediction, they are not the same and both look useful...

[LiamSkirrow]

Keep a register that gets incremented a branch prediction is wrong, this would be interesting to see over the course of the program...

[LiamSkirrow]

Branch target prediction is very simple to implement since it looks like RISCV does not define any indirect branch/jump instructions, but rather only defines branches/jumps to immediate values. Therefore, the branch target is obtained by performing a simple lookup on the current instruction encoding and grabbing the imm slice from the instruction.

However, branch prediction is a little more complicated since some level of computation has to be performed in order to check whether the conditional is satisfied, and given the conditional branches BEQ, BLT, BGT, BNE, BLTU and BGEU we require another ALU-like module. So, create the branch predictor as a separate module that gets instantiated within the control unit, and simply re-instantiate the existing ALU within the branch predictor module for convenience (I reckon this is better than simply creating an additional strippped down ALU module). If you like, include some ifdefs to create the simpler, stripped down branch predictor's ALU...

Turns out the math operations we have to perform are incredibly simple -> ie check for equality (BEQ, BNE) and check MSB in result of a subtraction (BGT, BLT etc)... we don't need to instantiate another ALU for this, just include the extra ~2 lines of code...