Lines Matching refs:bits

19 Since it's 33 bits long, bit 32 is always going to be set, so usually the
23 Note that a CRC is computed over a string of *bits*, so you have
24 to decide on the endianness of the bits within each byte.  To get
52 But also notice how the next_input_bit() bits we're shifting into
54 32 bits later.  Thus, the first 32 cycles of this are pretty boring.
61 can be precomputed, and merging in the final 32 zero bits to make room
82 As long as next_input_bit is returning the bits in a sensible order, we don't
83 *have* to wait until the last possible moment to merge in additional bits.
84 We can do it 8 bits at a time rather than 1 bit at a time:
102 If the input is a multiple of 32 bits, you can even XOR in a 32-bit
118 a 256-entry lookup table indexed by the high 8 bits.
125 It is not practical to process much more than 8 bits at a time using this
137 A "slicing by 2" technique would shift the remainder 16 bits at a time,
150 Each step, 32 bits of data is fetched, XORed with the CRC, and the result
152 leaves the low-order bits of the intermediate remainder zero, the
160 in parallel.  Each step, the 32-bit CRC is shifted 64 bits and XORed
161 with 64 bits of input data.  What is important to note is that 4 of
171 Normally, appending zero bits to a message which is already a multiple
173 a basic CRC will not detect appended zero bits (or bytes).  To enable
179 The same problem applies to zero bits prepended to the message, and a