Re: rigth crc32 implementation

On Apr 26, 2005, at 1:22 PM, Jose M Rodriguez wrote:

> El Martes, 26 de Abril de 2005 21:42, Marcel Moolenaar escribió:
>> On Tue, Apr 26, 2005 at 11:43:54AM +0200, Jose M Rodriguez wrote:
>>> My first think was use the libkern based one, but I found:
>>> sys/linkern/crc32.c
>>>
>>> - the code may not be endian safe.
>>
>> It operates on bytes, so it's endian-safe. Note that the uint32_t
>> that's returned is not subject to endianness issues: it's always
>> in the native byte order. The caller of crc32 needs to byteswap
>> if it needs to compare this integral with a CRC that's not in
>> the native byte order.
>>
>
> Yes, but this code come from a previous reduction: calculate the table
> from a xor/shift bit oriented alg.

True, but doesn't that imply that the reduction is endian-independent?
There's no big end and/or little end to a bit, so to speak. The values
in the table are the result of mathematical calculations, which by
definition do not depend on the endianness of the machine that was used
to compute them. Yes, the in-memory representation of those values do
differ but that's not the issue.

Or am I missing something (possibly very obvious)?

> Looking at sys/net/if_ethersubr.c ether_crc32_be() & ether_crc32_le(), 
> I
> became to doubt if we need two tables, with bitesex based #ifs.

I think those are 2 different algorithms altogether. As far as I can
tell, there's no need for it. A shift-right on a little-endian box
yields the same effect as a shift-right on a big-endian box. It
effectively divides the value by two. That you won't achieve if the
shift-right moves the bits towards the most-significant bit, right?

So why does one do a shift-right when the other does a shift-left?
Why does one define the carry as the least-significant bit and the
other as the most-significant bit?

Again: math has never been my strongest ability, so it's possible
that I simply have a mathematical cross-wire in my head preventing
me from thinking mathematically clearly :-)

-- 
  Marcel Moolenaar         USPA: A-39004          marcel_at_xcllnt.net