0
$\begingroup$

enter image description here

enter image description here

I have question about the ALUOp control signal.

When doing R type instructions, 31-26th bits are all 000000. What decides the instruction is actually the func field of 5-0th bits.

In that case, I wonder why the ALUOp signals for the R type(add,sub,and,or,slt) below the table should all differ. I don't know why ALUcontrol needs to receive data from both instruction and Control when ALUOp for R type looks useless.

Can't ALUcontrol tells ALU what operations to do by just receiving 5-0th bits? If so, all the ALUOp signal can be all same for the R type.

Thanks in advance!

$\endgroup$
  • $\begingroup$ Welcome to Computer Science! The title you have chosen is not well suited to representing your question. Please take some time to improve it; we have collected some advice here. Thank you! $\endgroup$ – Raphael Apr 10 '18 at 5:16
1
$\begingroup$

First, there is a source of confusion between the table you're showing and the diagram.  The table and diagram both use the term "ALUOp" but for the diagram this is the term for the output of the "Control" going into the "ALU control", whereas for the table this is the term for the output of the "ALU control" going into the ALU!

Can't ALUcontrol tell ALU what operations to do by just receiving 5-0th bits? If so, all the ALUOp signal can be all same for the R type.

Not directly, it doesn't appear so. I don't see a simple bit pattern in the bit 5-0 that would result in the proper "ALUOp" shown in the table, so a lookup is necessary, which is what "ALU control" is doing when the ALUOp coming from Control is for 000000 (R-type).

I don't know why ALUcontrol needs to receive data from both instruction and Control when ALUOp for R type looks useless.

This is because "ALU control" is also used by I-type instructions — lw & sw, addi/u, which use the add function of the ALU in computing an effective address, as well as slti, andi, ori, xori, which also require the ALU.  Note that the ALUOp for lw & sw is 010, the same as add (as they use the ALU to compute the effective address).  Further note that the ALUOp for sub and beq are also 110, which makes sense because a beq is comparing the two (albeit for equality, so xor might also have been used).

We don't see the other I-type instructions in the table, but you can imagine the slti/u also use ALUOp 110 for subtraction and addi/u also use 010 for addition, and that, andi, ori, xori, use the same codes as and, or, xor.


The J-type instructions have their own dedicated adders so, no need for ALUOp.

$\endgroup$
  • $\begingroup$ OH! I did not know the mismatch between the diagram and the table! I thought ALUOp of the table is what comes out from the "Control". So it actually is 0 and 1 that comes out from the "control" for the ALUOp! Thank you so much Erik! $\endgroup$ – kyung sub Song Apr 10 '18 at 14:50
  • $\begingroup$ Yeah, so I'm taking it that if it is an I-type instruction, then "Control" provides the final 3-bit ALU operation code from decode of instruction bits 31-26 (and "ALU control" just passes that through to the ALU), but if it is an R-type, then "ALU control" provides the final ALU operation code from instruction bits 5-0. ALU control has to know whether to pass thru the code from Control or decode from 5-0. Control will tell it, and it may do this with one special code (like 000) or it may send another separate bit to ALU control (to be used to decide). The diagram doesn't say. $\endgroup$ – Erik Eidt Apr 10 '18 at 15:33

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.