MIPS control signal table(R-type add)
For certain instructions in certain pipeline stages, we don't care about the results or operation of one or more of the hardware's many functional units. 

Let's say the processor implementation has several functional units, e.g. in the ALU, for addition/subtraction, one for and/or, one for multiplication, one for division, one for shifting, and maybe even (separate from the ALU) one for computing addressing, e.g. combined shift &amp; add for the various load &amp; store instructions.&nbsp; there may also be a completely separate adder next to the PC for doing pc-relative branches.

All that hardware is always there, but not all is always being used.

So, for example, when doing an unconditional branch instruction, the regular ALU is still there doing something, but we don't care about it.&nbsp; All we have to do is ignore the unit's output, e.g. don't write it to a register.

So, at the times when we don't care about the regular ALU's output, we also don't care about the signals going into the ALU &#8212; the source operands, and the code that says whether to add vs. and vs. other.&nbsp; We need to ignore not just the ALU's output, then but also any signals like overflow.&nbsp; However, that is pretty easy to do, so sometimes this is done (ignoring output while giving "don't care" input), instead of instructing the ALU to do something specific during don't care, like adding 0 + 0.

However, when it comes to memory we never want to initiate a memory reference with a potentially garbage address, even a read, let alone a write, which could be destructive of program state.&nbsp; Keep in mind that the memory reference goes thru the cache and then potentially off-chip, to the memory devices, and/or to I/O devices.&nbsp; We don't even want to issue a read to a known or hard-coded address (like 0).&nbsp; If the instruction isn't a memory reference, we should not touch memory at all!!&nbsp; And we do that by forcing both the read and write signals to 0.