From owner-freebsd-current@FreeBSD.ORG Tue Apr 26 21:28:42 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3F53316A4CE for ; Tue, 26 Apr 2005 21:28:42 +0000 (GMT) Received: from ns1.xcllnt.net (209-128-86-226.bayarea.net [209.128.86.226]) by mx1.FreeBSD.org (Postfix) with ESMTP id A016243D5D for ; Tue, 26 Apr 2005 21:28:41 +0000 (GMT) (envelope-from marcel@xcllnt.net) Received: from [192.168.4.250] (dhcp50.pn.xcllnt.net [192.168.4.250]) by ns1.xcllnt.net (8.13.3/8.13.3) with ESMTP id j3QLSdhs008529; Tue, 26 Apr 2005 14:28:39 -0700 (PDT) (envelope-from marcel@xcllnt.net) In-Reply-To: <200504262222.41463.josemi@redesjm.local> References: <200504261143.55195.josemi@redesjm.local> <20050426194208.GB7773@ns1.xcllnt.net> <200504262222.41463.josemi@redesjm.local> Mime-Version: 1.0 (Apple Message framework v622) Content-Type: text/plain; charset=ISO-8859-1; format=flowed Message-Id: Content-Transfer-Encoding: quoted-printable From: Marcel Moolenaar Date: Tue, 26 Apr 2005 14:28:39 -0700 To: Jose M Rodriguez X-Mailer: Apple Mail (2.622) cc: freebsd-current@freebsd.org Subject: Re: rigth crc32 implementation X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Apr 2005 21:28:42 -0000 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(),=20= > 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 :-) --=20 Marcel Moolenaar USPA: A-39004 marcel@xcllnt.net