There are smaller ways to encode a CRC32 table... - Kernel

This is a discussion on There are smaller ways to encode a CRC32 table... - Kernel ; The code to fill it in is smaller than the table itself. Is it worth complicating things with some INIT code to reduce the stored image size? (The table is not compressible.) #define CRC32POLY 0xedb88320 /* CRC32 polynomial, little-endian */ ...

+ Reply to Thread
Results 1 to 3 of 3

Thread: There are smaller ways to encode a CRC32 table...

  1. There are smaller ways to encode a CRC32 table...

    The code to fill it in is smaller than the table itself.
    Is it worth complicating things with some INIT code to reduce
    the stored image size? (The table is not compressible.)

    #define CRC32POLY 0xedb88320 /* CRC32 polynomial, little-endian */

    static uint32_t crctab32[256];

    void
    crc32init(void)
    {
    unsigned i, j;
    uint32_t crc = 1;

    crctab32[0] = 0;

    for (i = 128; i; i >>= 1) {
    crc = (crc >> 1) ^ ((crc & 1) ? CRC32POLY : 0);
    for (j = 0; j < 256; j += 2*i)
    crctab32[i+j] = crc ^ crctab32[j];
    }
    }

    The above code basically computes the CRCs of the bytes 0x80, 0x40, ... 0x01,
    and applies the identity crctab32[i^j] = crctab32[i] ^ crctab32[j].

    And BTW, storing the inverse of the CRC only catches trailing (after the CRC)
    all-zero padding. If this is not a problem, it's not necessary, although you
    still might want to do it just for consistency. This inversion changes the
    CRC of the entire image (body + CRC) from all-zero to a fixed non-zero value.
    (To be precise, to the (non-inverted) CRC of 0xffffffff.)
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  2. Re: There are smaller ways to encode a CRC32 table...

    George Spelvin wrote:
    > The code to fill it in is smaller than the table itself.
    > Is it worth complicating things with some INIT code to reduce
    > the stored image size? (The table is not compressible.)


    I think it matters not at all either way.

    -hpa

    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  3. Re: There are smaller ways to encode a CRC32 table...


    On Thu, 2008-01-31 at 23:53 -0500, George Spelvin wrote:
    > The code to fill it in is smaller than the table itself.
    > Is it worth complicating things with some INIT code to reduce
    > the stored image size? (The table is not compressible.)

    [snip]

    Thanks but since the code is only used when building the image I'm not
    too worried which way is used and I've tested the table based one ;-).

    > And BTW, storing the inverse of the CRC only catches trailing (after the CRC)
    > all-zero padding. If this is not a problem, it's not necessary, although you
    > still might want to do it just for consistency. This inversion changes the
    > CRC of the entire image (body + CRC) from all-zero to a fixed non-zero value.
    > (To be precise, to the (non-inverted) CRC of 0xffffffff.)


    I didn't know the precise details of why you might invert it, thanks for
    the info.

    Ian
    --
    Ian Campbell
    Current Noise: Reverend Bizarre - Sodoma Sunrise

    I am a man: nothing human is alien to me.
    -- Publius Terentius Afer (Terence)

    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

+ Reply to Thread