From owner-cvs-all@FreeBSD.ORG Thu Mar 10 06:55:50 2005 Return-Path: Delivered-To: cvs-all@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 76CA716A4CE; Thu, 10 Mar 2005 06:55:50 +0000 (GMT) Received: from mail11.syd.optusnet.com.au (mail11.syd.optusnet.com.au [211.29.132.192]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9AC9743D2D; Thu, 10 Mar 2005 06:55:49 +0000 (GMT) (envelope-from PeterJeremy@optushome.com.au) Received: from cirb503493.alcatel.com.au (c211-30-75-229.belrs2.nsw.optusnet.com.au [211.30.75.229]) j2A6tl0B001105 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Thu, 10 Mar 2005 17:55:48 +1100 Received: from cirb503493.alcatel.com.au (localhost.alcatel.com.au [127.0.0.1])j2A6tl7l016373; Thu, 10 Mar 2005 17:55:47 +1100 (EST) (envelope-from pjeremy@cirb503493.alcatel.com.au) Received: (from pjeremy@localhost)j2A6tl7i016372; Thu, 10 Mar 2005 17:55:47 +1100 (EST) (envelope-from pjeremy) Date: Thu, 10 Mar 2005 17:55:47 +1100 From: Peter Jeremy To: Colin Percival Message-ID: <20050310065547.GA16318@cirb503493.alcatel.com.au> References: <200503091923.j29JN4Ti063868@repoman.freebsd.org> <422F50A6.907@criticalmagic.com> <422F55C6.3000207@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <422F55C6.3000207@freebsd.org> User-Agent: Mutt/1.4.2i cc: cvs-src@freebsd.org cc: src-committers@freebsd.org cc: cvs-all@freebsd.org Subject: Re: cvs commit: src/lib/libmd Makefile sha256.3 sha256.h sha256c.c shadriver.c src/sbin/md5 Makefile md5.c X-BeenThere: cvs-all@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: CVS commit messages for the entire tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Mar 2005 06:55:50 -0000 On Wed, 2005-Mar-09 12:00:06 -0800, Colin Percival wrote: >it. As for md5 and sha1, it's useful to have a minimalist libmd for >applications which don't require the bloated monst^W^W^W OpenSSL, and >these are small enough that a bit of duplication really doesn't matter. The problem isn't the bloat, it's the maintenance effort. Three almost, but not totally, identical versions of foo() means three times as much maintenance effort and a non-zero probability of someone forgetting to make a change to one of the versions. >Assembly optimization might be worthwhile; but for this sort of code, I >think you'd need to have a version optimized for each *processor* rather >than each *platform* in order to get any significant gain. Not necessarily. MD5 and SHA-x both use operations (like rotate) that are primitives in at least some of the CPUs that we support but not in C. Model-specific code would be nicer - and having only one copy of the relevant functions would make it a lot easier to support lots of different code variants. (Of course, it would be nice if FreeBSD included the hooks to support model-specific code ala Solaris). > These hash >functions are designed for 32-bit processors in a manner which makes it >fairly hard for the compiler to get things wrong. It's not so much getting things wrong as being able to get the right answer quicker. It may not be obvious to the compiler that a = (a << 5) | (a >> 27); can be replaced by rotl a,5 and someone with a suffiently warped point of view is likely to manage to find novel ways to express the algorithm that the compiler would never think of. -- Peter Jeremy