Is a carry bit generated when doing bit-wise shift left in MT?


Steve,

My test is just for a single APC, so button columns 1-8
I commented your code to make it easier for me to follow. I couldn’t understand the code at the end. Could you please explain it to me:
// Set all marked values to 1
tt=tt|uu
// And set back to normal
tt=tt^-1
// Now or with new values
ss=ss<<rr
tt=tt|ss
ga=tt

I’m not getting the results I expected, which were:

Column of pressed button=1 Target Block = 1 Result in target block =4 (100 binary)

Column of pressed button=2 Target Block = 1 Result in target block =2 (010 binary)

Column of pressed button=3 Target Block = 1 Result in target block =1 (001 binary)

Column of pressed button =4 Target Block= 2 Result in target block =4 (100 binary)

Column of pressed button =5 Target Block= 2 Result in target block =2 (010 binary)

Column of pressed button =6 Target Block= 2 Result in target block =1 (001 binary)

Column of pressed button=7 Target Block = 1 Result in target block =2 (010 binary)

Column of pressed button =8Target Block= 1 Result in target block =1 (001 binary)

I’ve attached the code and also the log window contents. I hope you can figure out where the problem lies. Probably I’m misunderstanding some of the variables. Files are in Open Office format. No problem opening them, I hope.

Thanks,

Gabriel


Attachments:
1489925474104_STEVES-CODE.odt
1489925490792_LOG-WINDOW-STEVES-CODE.odt

My test is just for a single APC, so button columns 1-8
I commented your code to make it easier for me to follow. I couldn’t understand the code at the end. Could you please explain it to me:
// Set all marked values to 1

Comment:

In this point tt is the complimented value of the original ga value. We OR it with the mask 7 (111) shifted into the correct
position to ensure these bits are all set. Later we complement (XOR) the value again to ensure those 3 bits are cleared and the
original bits are set back to their proper value
—-
tt=tt|uu
// And set back to normal

Comment:
This is the XOR function takes all bits as one and makes them zero and visa versa. Now tt has the value of ga but with
the target block bits all cleared. The -1 is the Bome representation of FFFF FFFF hext (all ones)
——
tt=tt^-1

Comment:
The below takes the new target value and shifts it into the correct block

// Now or with new values
——
ss=ss

Here is the project file I’ve been working to test with as promised in my last comment. Apparently you cannot add attachments to comments on this system


Attachments:
1489936975962_bit-manipulatoni-2017-03-18.bmtp

Upon opening you file, it looks like you are marking your block numbers left to right which is probably not good if you want to add additional block in the future (you have room for 2 more. I have been using right to left numbering with lsb with in the block on the right.

At the beginning of you code you will need to convert the input block number pp as follows to get left to right numbering

first
// look for invalid block number
if pp > 7 then exit rules, skip outgoing action
// Reverse order the blocks
pp=pp-7

I will wait until you applied the fix above before evaluating any further. Yes, I remember at some point you said you were marking block numbers in reverse order but somewhere along the line I forgot.

Steve,

Many, many thanks for your resolve to answer my question, and for providing the sophisticated code to do it…. and for helping me to understand what was involved.

The algorithm works perfectly. My project creeps ever closer to completion.

Gabriel

My pleasure, Gabriel I might not have time to do that level of detail in the future so if you need simple guidance. I can help here, however for more complex situations if you need me to help you code things, you can reach me at bome@sniz.biz for any fee based services. I will continue to monitor this forum and help as I can as time permits.

Regards,

Steve