Boost C++ Libraries

For a given degree x for the modulo-2 polynomial divisor, the remainder will have at most x terms (from degree x - 1 down to the constant term). The coefficients are modulo-2, which means that they can be represented by 0's and 1's. So a remainder can be modeled by an (unsigned) integer of at least x bits in width.

The divisor must have its x degree term be one, which means it is always known and can be implied instead of having to explicitly include in representations. Its lower x terms must be specified, so a divisor can be modeled the same way as remainders. With such a modeling, the divisor representation could be said to be truncated since the uppermost term's value is implied and not stored.

The remainder and (truncated) divisor polynomials are stored as basic computer integers. This is in contrast to the dividend, which is modeled from the input stream of data bits, where each new incoming bit is the next lower term of the dividend polynomial. Long division can be processed in piecemeal, reading new upper terms as needed. This maps to reading the data a byte (or bit) at a time, generating updated remainders just-in-time, without needing to read (and/or store(!)) the entire data message at once.

Long division involves appending new dividend terms after the previous terms have been processed into the (interim) remainder. So the remainder it the only thing that has to change during each division step; a new input byte (or bit) is combined with the remainder to make the interim dividend, and then combined with the partial product (based on the divisor and top dividend bit(s)) to become a remainder again.

When all of the input data has been read during division, the last x bits are still stuck in the interim remainder. They have not been pushed through the division steps; to do so, x zero-valued extra bits must be passed into the system. This ensures all of the message's data bits get processed. The post-processed remainder is the checksum. The system requires the message to be augmented with x extra bits to get results.

Alternatively, if the post-division augmentation bits are the expected checksum instead, then the remainder will "subtract" the checksum with itself, giving zero as the final remainder. The remainder will end up non-zero if bit errors exist in either the data or checksum or both. This option requires the checksum to be fed from highest-order bit first on down (i.e. big endian).

Exploiting the properties of how the division is carried out, the steps can be rearranged such that the post-processing zero-valued bits are not needed; their effect is merged into the start of the process. Such systems read unaugmented messages and expose the checksum directly from the interim remainder afterwards. (You can't use the "augment-message-with-checksum-and-zero-check" technique with this, of course.)

Since long division proceeds from the uppermost terms on down, it's easiest to treat an incoming byte as the uppermost unprocessed terms, and to read the bits within that byte as the highest-order bit is the uppermost unprocessed term and go down. However, some hardware implementations have an easier time reading each byte from the lowest-order bit and go up. To simulate those systems in software, the program needs to be flagged that input reflection needs to be applied. Reflecting a built-in integer reverses the order of its bits, such that the lowest- and highest-order bits swap states, the next-lowest- and next-highest-order bits swap, etc. The input reflection can be done by reflecting each byte as it comes in or keeping the bytes unchanged but reflect the other internal functioning. The latter sounds harder, but what it usually done in the real world, since it's a one-time cost, unlike reflecting the bytes.

Similarly, the final remainder is processed by some hardware in reverse order, which means software that simulate such systems need to flag that output reflection is in effect.

Some CRCs don't return the remainder directly (reflected or not), but add an extra step complementing the output bits. Complementing turns 1 values into 0 values and vice versa. This can simulated by using a XOR (exclusive-or) bit mask of all 1-values (of the same bit length as the remainder). Some systems use a final XOR mask that isn't all 1-values, for variety. (This mask takes place after any output reflection.)

At the other end, the built-in-integer register normally starts at zero as the first bytes are read. Instead of just doing nothing but load input bits for x steps, some CRC systems use a non-zero initial remainder to add extra processing. This initial value has to be different for the augmented versus un-augmented versions of the same system, due to possible incorporation with the zero-valued augment bits.

The Rocksoft™ Model CRC Algorithm, or RMCA for short, was designed by Ross Williams to describe all the specification points of a given CRC system (quoted):

His description assumes an octet-sized byte. The POLY is the (truncated) divisor. The INIT is the initial remainder, assuming the unaugmented version of CRC processing is used. (If you're using an augmented-style CRC, you have to undo the effect of the built-in zero-augment before initialization.)