I'm trying to XOR 3 values: 0x04, 0x9F, and 0xC5. The values 0x9F and 0xC5 are coming from registers while 0x04 is a constant.
The result should be 0x5E but the output of the XOR is 0x5A (which is the result if the 0x04 input wasn't there). However, if I XOR 0x04 with any of the other values on their own with a 2-input XOR gate, that result is correct. So my temporary solution has been to XOR 0x04 with 0xFF and then XOR this result with the 0xC5 value.
This must be a bug, right?
Thanks
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Thanks for your reply. That's what I've done to bypass the bug. However, I now need to XOR four values: 0x35, 0x0E, 0x3C, and 0xB1. The result must be 0xB6, but Logisim says it's 0x82. I don't want to have to use multiple XOR gates when I could be using one :(
Logisim is a fantastic program, I really like it. But this bug in the XOR module is becoming problematic. My project is highly dependent on XOR gates (I currently have 242 and still have many more to add). I'm really hoping this bug can be fixed in the next release.
Thanks
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
This is not a bug, but rather a design decision that you happen to disagree with. How XOR is "supposed" to work is more controversial than you seem to think. By default, Logisim takes the interpretation that a XOR gate means "exactly one" bit must be set: Thus, the XOR of three 1's is 0, since more than one of input is 1. I know you think that the XOR of three 1's should be 1, since an odd number of bits are 1. If Logisim were changed to work your way by default, then others would complain that I broke the XOR gate - admittedly fewer people, but still a substantial fraction of Logisim users.
Fortunately, Logisim does have the ability for you to modify the XOR gate's behavior: With the XOR gate selected, go to the attribute table in the lower-left corner, and modify "Multiple-Input Behavior" to "When an odd number are on." Alternatively, you can use an Odd Parity gate.
-Carl
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Thanks for your reply and suggestion, it works now as I need it. Yay! :)
There's nothing with which I disagree, I simply didn't understand why I wasn't getting what I expected. I do agree that three 1's is 0 for an XOR gate, however, I need the "wrong way" as I'm dealing with data and not logic (if that makes a difference).
Thanks for your clarification and help. Great job with Logisim, and I apologise for calling it a bug.
Regards,
JP
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I'm trying to XOR 3 values: 0x04, 0x9F, and 0xC5. The values 0x9F and 0xC5 are coming from registers while 0x04 is a constant.
The result should be 0x5E but the output of the XOR is 0x5A (which is the result if the 0x04 input wasn't there). However, if I XOR 0x04 with any of the other values on their own with a 2-input XOR gate, that result is correct. So my temporary solution has been to XOR 0x04 with 0xFF and then XOR this result with the 0xC5 value.
This must be a bug, right?
Thanks
I have the same result. A xor B xor C should be equivalent to (A xor B) xor C but it isn't.
You can work around using two gate xor's (see picture)
http://ubuntuone.com/1PWx647WxkQ18O
sourceforce didn't show the picture: here it is :
must be http://ubuntuone.com/1PWx647WxkQ18OxbB2Wcej
sorry
Thanks for your reply. That's what I've done to bypass the bug. However, I now need to XOR four values: 0x35, 0x0E, 0x3C, and 0xB1. The result must be 0xB6, but Logisim says it's 0x82. I don't want to have to use multiple XOR gates when I could be using one :(
Logisim is a fantastic program, I really like it. But this bug in the XOR module is becoming problematic. My project is highly dependent on XOR gates (I currently have 242 and still have many more to add). I'm really hoping this bug can be fixed in the next release.
Thanks
This is not a bug, but rather a design decision that you happen to disagree with. How XOR is "supposed" to work is more controversial than you seem to think. By default, Logisim takes the interpretation that a XOR gate means "exactly one" bit must be set: Thus, the XOR of three 1's is 0, since more than one of input is 1. I know you think that the XOR of three 1's should be 1, since an odd number of bits are 1. If Logisim were changed to work your way by default, then others would complain that I broke the XOR gate - admittedly fewer people, but still a substantial fraction of Logisim users.
Fortunately, Logisim does have the ability for you to modify the XOR gate's behavior: With the XOR gate selected, go to the attribute table in the lower-left corner, and modify "Multiple-Input Behavior" to "When an odd number are on." Alternatively, you can use an Odd Parity gate.
-Carl
Thanks for your reply and suggestion, it works now as I need it. Yay! :)
There's nothing with which I disagree, I simply didn't understand why I wasn't getting what I expected. I do agree that three 1's is 0 for an XOR gate, however, I need the "wrong way" as I'm dealing with data and not logic (if that makes a difference).
Thanks for your clarification and help. Great job with Logisim, and I apologise for calling it a bug.
Regards,
JP