Re: rigth crc32 implementation

El Martes, 26 de Abril de 2005 23:28, Marcel Moolenaar escribió:
> 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 :-)

I think so.  Also, I found no driver use both, and we have ether drivers 
that works in all platforms.  So this will cover diff between the 
system and the chip.

This make sense.

So, what about add those 2/3 functions.  I'll prefer this to carry 
another private version of crc32.

--
  josemi