So I have a word, and I want to loop through and test the left most bit. I have my word and I'm passing it to my subroutine, I know how to build a loop, I'm just not sure how to test the left most bit in the word.
Thanks for any help
The best way to do this is with bit masking -- perform a bitwise AND between the word you want to check and a bit mask with a 1 in any position you wish to test. i.e. in binary:
my word: 11
bitmask: 10
& ==
10
you can see that the 1 in the left side drops out. So to do something similar on a 16bit number:
0x0230 & 0x8000 = 0x0000
0xC020 & 0x8000 = 0x8000 != 0x0000
The important thing to note here is that if the bit is not present the AND returns a 0, and if the bit is present it returns something else. It doesn't matter what it is, just that it's not zero.
Not sure if it applies to your specific task but a simple approach could be performing a logical/arithmetic left shift to the word. This is simply done by adding the word to itself (which is equal to multiplying by 2 and thus shifting all the bits to the left 1 "spot). After doing this, the condition codes will be set (assuming you're using the GPRs) and you can test if the left most bit is a 1 or a 0 by checking if the shifted word is positive OR zero (hence the left most bit is a 0), or negative (hence the left most bit is a 1). Loop over the whole word following this approach and you'll be able to determine the value of each bit in your word. Hope this helps.
Related
I'm working on a problem out of Cracking The Coding Interview which requires that I swap odd and even bits in an integer with as few instructions as possible (e.g bit 0 and 1 are swapped, bits 2 and 3 are swapped, etc.)
The author's solution revolves around using a mask to grab, in one number, the odd bits, and in another num the even bits, and then shifting them off by 1.
I get her solution, but I don't understand how she grabbed the even/odd bits. She creates two bit masks --both in hex -- for a 32 bit integer. The two are: 0xaaaaaaaa and 0x55555555. I understand she's essentially creating the equivalent of 1010101010... for a 32 bit integer in hexadecimal and then ANDing it with the original num to grab the even/odd bits respectively.
What I don't understand is why she used hex? Why not just code in 10101010101010101010101010101010? Did she use hex to reduce verbosity? And when should you use one over the other?
It's to reduce verbosity. Binary 10101010101010101010101010101010, hexadecimal 0xaaaaaaaa, and decimal 2863311530 all represent exactly the same value; they just use different bases to do so. The only reason to use one or another is for perceived readability.
Most people would clearly not want to use decimal here; it looks like an arbitrary value.
The binary is clear: alternating 1s and 0s, but with so many, it's not obvious that this is a 32-bit value, or that there isn't an adjacent pair of 1s or 0s hiding in the middle somewhere.
The hexadecimal version takes advantage of chunking. Assuming you recognize that 0x0a == 0b1010, you can mentally picture the 8 groups of 1010 in the assumed value.
Another possibility would be octal 25252525252, since... well, maybe not. You can see that something is alternating, but unless you use octal a lot, it's not clear what that alternating pattern in binary is.
Now I'm trying to figure out best method for iterating over bits in FPGA. I'm using some variation of fast powering algorithm, a.k.a exponentiation by squaring (more precisely it's doubling and add algorithm for elliptic curve mathematics). To implement it on hardware, I know I must use FSM which does iteration. My problem is how to properly "handle" moving from bit to bit. My first thought was to switch order of bytes, but when my k = 17 is 32bit, I must discard first 27 bits, so it's rather stupid idea. Another concept was with "moving" 0001000 pattern and bitwise & it with number, but it also requires to find first nonzero bit.
TL&DR
Got for example k = 17 (32bits, so: 17x0 10001) and want to iterate 5 times (that means I start iteration on first "real" bit of number) knowing each bit I iterate over.
Language doesn't matter - I need only the algorithm, not solution in specific language. However, if it is easily done in Verilog, I wouldn't mind. :P
A dedicated combinatorial circuit to find the first nonzero bit, shift it to the first position and tell you the shift amount should be fairly light on resources.
In principle, the compiler should be able to find this solution on its own and improve on it:
if none of the top 16 bits are set, set bit 4 of the shift amount, and shift by 16.
if none of the top 8 bits are set, set bit 3 of the shift amount, and shift by 8.
...
The compiler should be able to find further optimizations on this.
Don not code for FPGA but still:
rewrite algorithm to iterate number x from LSB to MSB
then in each iteration bit shift x right by 1 bit
stop if x==0.
this way you have bit-scan inside your main loop and do not need additional cycles for it.
x!=0 is done easily by ORing all its bits together
C++ code example:
DWORD x = ...;
for (; x != 0; x >>= 1)
{
//here is your iteration loop stuff like:
if (DWORD(x & 1) !=0 ) ...;
}
Something like:
always # *
casex(num)
8XXX_XXXX: k = 32;
4XXX_XXXX: k = 31;
2XXX_XXXX: k = 30;
...
Should give you the value of k.
You can have a shift register which can be parallel loaded so you can write a 1 to the kth bit, so you know when your iterations have ended.
If you loop from 0 to 31 and discard the 27 leading zeros...you aren't necessarily wasting cycles. Depends on whether you've surrounded this with a synchronous process, or a asynchronous one.
One gives you a rather small clocked circuit with a 32 clock latency.
The other gives you a giant rats nest of ANDs and ORs which won't run at a very high frequency.
Depends on what you want. Remember though, that even if you do decide to loop over 32 clocks, you can PIPELINE it such that you start a new calculation every clock. It might take you 32 clocks to get an answer, but you CAN do them at high speed.
I have been hanging on it too much time...
I've read «A Painless Guide to CRC Error Detection Algorithms» several times. May be I not completely understand theory, but practice seems as clear as sky, but something wrong.
I'm not about code and particular realization, but conceptual (a plain method).
I do this:
1. Take a single byte.
2. Take a uint and fill it with 0xffffffff.
3. Check if the highest bit is 1.
4. Shift one bit to the left.
5. Put the next bit from source byte.
6. It Step3 checking is true, then XOR it with 0x04C11DB7.
7. After data is end, reverse (reflect) working uint.
8. XOR it with 0xffffffff
And it works... but only with zeros (I've checked 1,2,3,4 bytes of zeros). But when I take a byte 0x01 it fails (online calculators show different result). I just can't catch what am I doing wrong.
Step by step (mine version with lowest bit first):
01.Initialization 0xffffffff
02.Shift<< 0fffffffe
03.Place that single 1 0xffffffff
04.XOR 0xfb3ee248
05.Shift<< 0xf67dc490
06.XOR 0xf2bcd927
07.Shift<< 0xe579b24e
08.XOR 0xe1b8aff9
09.Shift<< c3715ff2
10.XOR 0xc7b04245
11.Shift<< 0x8f60848a
12.XOR 8ba1993d
13.Shift<< 0x1743327a
14.XOR 0x13822fcd
15.Shift<< 0x27045f9a
16.Shift<< 0x4e08bf34
17.Reflect 0x2cfd1072
18.XOR (0xffffffff) 0xd302ef8d (the result)
Please help! What is wrong with it?
At last, I've got the reciept. It took much time, but I reinvented it ))
Share it with anyone, who need it:
1. Take first 4 bytes from message (if it less than 4 byte - add zeros). May be you will need to reflect bits in EVERY byte (I have to, but I think it depends on particular architecture). Put it into Register (uint).
2. Make Register XOR 0xFFFFFFFF.
3. Shift one bit left.
4. Place the next message's bit (the lowest one first) to the right side of Register.
5. If shifted bit was 1, than Register XOR 0x04C11DB7.
6. Do steps 3-5 until the end of the message.
7. Do steps 3-5 for 32 bits of zeros (if the message is less than 32 bits, than this number must correspond with input length).
7. Reflect bits in the whole Register.
8. Make Register XOR 0xffffffff.
That's it - you have the CRC32, which all online calculators show and, at least, correct for deflate, PNG, etc.
I am asked on HW to reverse bits, like mirror flip them so for example 1011 0100 becomes 0010 1101, using shift and rotate combination. I understand how those commands work but I can't think of a way to flip them. Thanks.
I need to do it using SAL assembly language.
If you need to flip a b-bit word using only shifts, you could emulate a stack:
b times{
right shift on the input register, setting a carry flag.
left shift on the output register, reading the carry flag.
}
Note that x86 has the "rotate through carry" instructions - they serve both purposes (or use rotation without carry on the input register to preserve the input). If left shift from carry is not available but right shift from carry is, reverse the words "left" and "right" in the previous algorithm. If no shift from carry is available, you need to emulate by an "ordinary" logical shift followed by setting the correct bit, but...
If you can use AND and OR as well and b is known ahead and is a power of two, there is a faster way. Reverse two bits within each pair, then two pairs within each nibble, then two nibbles within each byte, then two bytes within each word...
for 8-bit x:
//1234 5678
x = (0x55 & x)<< 1 | (0xAA & x)>> 1 //2143 6587
x = (0x33 & x)<< 2 | (0xCC & x)>> 2 //4321 8765
x = (0x0F & x)<< 4 | (0xF0 & x)>> 4 //8765 4321
So I am working on a program in LC3 and I am having a issue with masking. I am fine with creating a mask of all 1's of the appropriate length, fine shifting everything to the appropriate field, but I can't for the life of me shift things back over to the right once I am done doing the AND comparison. How do you right shift in LC3? I saw something on iteration comparison, but I don't know how to compare bits in different positions, and to compare them in the same position I would have to shift one to the right eventually anyway. Am I missing something?
To simulate right shift, you just need to make two masks, one for source bit and one for destination bit:
src_mask=0x04; // read from bit position 2
dst_mask=0x01; // write to bit position 0
while(src) { // or while src_mask, because that too will eventually go to zero
if (src & src_mask) dst+=dst_mask; // or dst|=dst_mask
src &= (~src_mask);
dst_mask=dst_mask+dst_mask;
src_mask=src_mask+src_mask;
}
You might not need to do a right shift in this situation at all -- just save the starting field before shifting it left, then restore it from memory afterwards.