1

Assuming that the current PC is 0x00400010 (after increment) and the target label has the value of 0x00400040. What is the binary value of the constant in the instruction?

beq $s0, $s0, target

I'm not really sure how to approach this question. I would appreciate a hint, or explanation of how to find a solution to this.

Marco
  • 2,007
  • 17
  • 28
  • 1
    *What is the binary value of the constant in the instruction?* - What constant? – Marco Sep 23 '17 at 00:52
  • I'm not sure what it means when it asks for the binary value of the constant –  Sep 23 '17 at 01:16
  • 1
    Could you please be more specifc because I can't understand the problem you are facing? You don't understand what `beq` does? You don't understand what happens to PC? What's the problem? – Marco Sep 23 '17 at 01:32
  • 1
    It would be pretty easy to create the situation you describe using a simulator like SPIM or MARS, and then just look at the machine code it generates. – Michael Sep 23 '17 at 09:43
  • Ok, I'm looking at my course materials and it seems that the 'constant' is part of the I format. It is the last 16 bits of the opcode. My issue was simply tracking what happens to those 16 bits. Thanks everyone for your input and help! –  Sep 25 '17 at 00:05

1 Answers1

0

I am not sure if I have understood your question. I am assuming that you are asking for the offset which will be coded into the instruction.

Since the target is at 0x00400040 and the current PC is at 0x00400010, the offset probably will be 0x00000030 (because 0x00400040 - 0x00400010 = 0x00000030). This can be easily converted into the binary format you asked for:

0000 0000 0000 0000 0000 0000 0011 0000

But please note that I don't know MIPS. In some processor architectures, the offset coded into the instruction is

(target PC) - ((current PC) + (size of current instruction))

Since I don't know MIPS, I don't know what the byte size of the beq instruction is. Thus, I can't compute the offset for this case. If you tell me the size of the beq instruction, I'll make an edit to that answer and add that.

Furthermore, in most processor architectures, relative offsets will be restricted for most instructions. Once again, I don't know MIPS, but chances are that the offset is limited to 16, 12 or even 8 bits. In that case, to get the actual binary offset representation, remove zeroes from the left from the binary number I gave above until only the bits which are used to store the offset are left.

EDIT (taking into account Busy Beaver's comment)

On MIPS, it seems that instructions are aligned to 32 bits / 4 bytes. This allows to store the actual offset needed divided by 4 (the CPU then reads the offset and multiplies it by 4 to compute the actual target). The advantage is that you can store bigger offsets with the bits given. In other words, you save 2 offset bits that way.

In your example, the PC should jump by 0x00000030 bytes to get to the target. The offset stored in the instruction then would be 0x00000030 / 4 which is the same as 0x00000030 >> 2 which is 0x0000000C0. You asked for the binary representation:

0000 0000 0000 0000 0000 0000 0000 1100

When decoding / executing the instruction, the CPU automatically multiplies that offset by four and that way gets back the real offset desired.

Binarus
  • 4,005
  • 3
  • 25
  • 41
  • 2
    Mmh, I don't think this is what happens. `beq $s, $t, offset` branches if the two registers are equal and, in case, advances PC of `offset<<2`. So if `target` is `0x00400040` then nPC would become `PC + (0x00400040)<<2` – Marco Sep 23 '17 at 11:12
  • 1
    @BusyBeaver Thanks for your comment and +1. As I said, I don't know MIPS, but obviously the instructions must be aligned to 4 bytes there. I will edit my answer accordingly. – Binarus Sep 24 '17 at 06:22