bit or'ing question [RESOLVED]

Hello everyone.

I had a quick question for the following

Assume $t0 holds 0x12001F10 after executing the instruction 'ori $t0, $t0, 784', which is the possible value of $t0 before executing this instruction?

A. 0x12001B11
B. 0x12000C00
C. 0x12001B10
D. 0x12001C00

The answer is infact D.

But i must have made a lucky guess i thought u solved this problem by doing the following:

converting 0x12001F10 to binary, and then converting each of A-D and or'ing each one with $t0, and if you come out with the address in $t0 = 0x12001F10 you've selected the right one. But if u say convert B to binary and or that with $t1 you still come out with $t1 even though B is inncorrect so that can't be the method. So i thought maybe you convert the number 784 and or that with the value in $t1, but this is also incorrect, you'll just end up getting 0x12001F10 which isn't even a choice but its what u started out with.


So finally I converted 784 to binary and or'ed that with each poisslbe answer and I figured it out while typing this message. Is there an easier way to get the answer rather than just elimination? On the exam i doubt i will have enough ttime to convert each choice to its equivlent binary form and or it with the number given if she has more than 4 choices.

Code:

---

0000 0000 0000 0000 0011 0001 0000  784
0001 0010 0000 0001 1110 0000 0000  0x12001C00
0001 0010 0000 0001 1111 0001 0000  ori
1        2    0      1      F      1      0

---

which is what $t0 holds

Well, you can take some shortcuts.
As you see, the binary representation of 784 doesn't have anything beyond the tenth bit set. This means that you can immediately kick out all answers that differ from the result in a higher bit, i.e. any hex digit after the third (from the right) is different.

Then I would do it like this:
1) Convert the relevant digits of the result to binary. In this case, that would be 1F10 of the answer, or 111100010000, of which I discard the two highest bits, leaving me with 1100010000. I check this against the fixed operand, i.e. 784 or 1100010000. The important thing here are the digits that are 0 in both operand and result. Everything that's 1 in the operand is irrelevant. Let's replace it with x. This leaves me with xx000x0000. I can discard the leftmost xs, leaving me with 000x0000. Now I convert just the lowest byte of each answer and compare it: the 0s must match, the places where I have an x are irrelevant.

To put this into practice.
Operand has 10 bits, approx. 3 hex digits. The result above that is 0x12001. A, C and D are the same, B is not. Strike B.
The difference between the 10 bits and the 3 hex digits is the highest two bits. Convert the third hex digit of each answer and compare the higher two bits to the result (F = 1111).
A: B = 1011, differs. Strike.
C: B = 1011, differs. Strike.

By exclusion, we're already done. Let's invent the additional E to keep things interesting. E = 0x12001C01.
D: C = 1100, matches. Keep.
E: C = 1100, matches. Keep.

Now we get to the point where we match the last two nibbles against the mask 000x0000.
D: 00 = 00000000, matches. Keep.
E: 01 = 00000001, differs. Discard.

And we're left with D.
Note that OR is lossy. Let's take another answer, F = 0x12001C10. It matches the first test again. On the second:
F: 10 = 00010000, matches. Keep.
Both D and F would be valid answers, although they differ. Of the three common binary bitwise operators AND, OR and XOR, only XOR is fully reversible.

Thanks again! thats alot easier and faster!

Much simpler:

784 = 0x310

The right end of the current state is 0xF10
(We don't need to look at any bits to the left of this, because oring won't change any bits to the left, so B is eliminated right away.)

1111 0001 0000
or'ed with
0011 0001 0000

The first byte (leftmost) could have been anything from C to F, so the rightmost 3 bytes of $t0 were 0xC10, 0xD10, 0xE10 or 0xF10. Oring made the second byte 1 but didn't change the 3rd byte. The left end was 0x12001, regardless. The only answer that fits is D.

You forgot 0xC00, 0xE00 or 0xF00.

And you essentially just described the same process I used, but in a way that took me a long time to understand.