CRC32 functions in libbb

[Rob Landley]

On Sunday 09 April 2006 7:20 am, Rob Sullivan wrote:
> Size results:
> After implementing the use of bb_crc32_filltable in decompress_bunzip2.c
> and gzip.c, there didn't appear to be any change in size. I then replaced
> the gzip.c CRC code with a call to bb_crc32_calc, which resulted in a size
> decrease of 4 bytes.

Cool.  I never did optimize busybox's gzip implementation.

What's the speed hit for the jump out of line?

> The only problem is that the way CRC calculation is implemented in
> read_bunzip in decompress_bunzip2.c doesn't easily allow itself to be
> replaced by a library call

I know.  I wrote it.

> - it's intermingled with decompression code 
> within a loop that gradually supplies data, whereas the bb_crc32_calc
> function calculates the CRC of all the data straight away. If I adapted
> bb_crc32_calc so that it could be supplied with data gradually, there
> really would be very little point in having a function call at all, as the
> function would only be around two lines long.

Moving table generation out of line makes a certain amount of sense.  Moving 
the actual crc calculation out of line has a speed hit in code that actually 
tends to care about that...

> Nevertheless, there is a slight size decrease, and I think that having
> crc32.c separately makes CRC implementation a little cleaner in Busybox
> generally. In view of implementation "niceness", even just having a
> separate bb_crc32_filltable would be good, despite no reduction in size, as
> it avoids code in triplicate (bunzip2, gzip, cksum).

Except the big endian and little endian versions aren't the same code, so it's 
two instances in three places.  Except there's four places if gzip and gunzip 
are both using the code...

> Of course, I could be seeing all this through the rose-coloured glasses of
> the coder...

If we're adding a command line crc32 utility, and gzip/gunzip/cksum all use 
the same algorithm, it would make sense to at least try and merge that.  
Worry about bunzip after handling that.  (And I have bzip deflate code I can 
dig up if anybody cares, and that would be a second instance of that style of 
crc...)

> Rob

Other Rob
-- 
Never bet against the cheap plastic solution.