Date: Tue, 26 Apr 2005 23:47:38 +0200 From: Jose M Rodriguez <josemi@freebsd.jazztel.es> To: Marcel Moolenaar <marcel@xcllnt.net> Cc: Jose M Rodriguez <josemi@freebsd.jazztel.es> Subject: Re: rigth crc32 implementation Message-ID: <200504262347.39919.josemi@redesjm.local> In-Reply-To: <ca65daa6ade5e2e190ad653fc8906a3f@xcllnt.net> References: <200504261143.55195.josemi@redesjm.local> <200504262222.41463.josemi@redesjm.local> <ca65daa6ade5e2e190ad653fc8906a3f@xcllnt.net>
next in thread | previous in thread | raw e-mail | index | archive | help
El Martes, 26 de Abril de 2005 23:28, Marcel Moolenaar escribi=F3: > On Apr 26, 2005, at 1:22 PM, Jose M Rodriguez wrote: > > El Martes, 26 de Abril de 2005 21:42, Marcel Moolenaar escribi=F3: > >> 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 =042 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=20 that works in all platforms. So this will cover diff between the=20 system and the chip. This make sense. So, what about add those 2/3 functions. I'll prefer this to carry=20 another private version of crc32. =2D- josemi
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200504262347.39919.josemi>