From owner-freebsd-amd64@FreeBSD.ORG Fri Mar 12 11:05:43 2004 Return-Path: Delivered-To: freebsd-amd64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 32ED716A4CE for ; Fri, 12 Mar 2004 11:05:43 -0800 (PST) Received: from dogfood.jrv.org (rrcs-sw-24-73-246-106.biz.rr.com [24.73.246.106]) by mx1.FreeBSD.org (Postfix) with ESMTP id C526243D1D for ; Fri, 12 Mar 2004 11:05:42 -0800 (PST) (envelope-from james@jrv.org) Received: from jrv.org ([192.168.3.33]) (authenticated bits=0) by dogfood.jrv.org (8.12.11/8.12.10) with ESMTP id i2CJ5RHP037375 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 12 Mar 2004 13:05:27 -0600 (CST) (envelope-from james@jrv.org) Message-ID: <405209FB.7020108@jrv.org> Date: Fri, 12 Mar 2004 13:05:31 -0600 From: "James R. Van Artsalen" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Peter Wemm References: <4051A841.9020205@thejemreport.com> <200403121025.28913.peter@wemm.org> In-Reply-To: <200403121025.28913.peter@wemm.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit cc: Jem Matzan cc: freebsd-amd64@freebsd.org Subject: Re: Peer review of AMD64/FreeBSD article X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Mar 2004 19:05:43 -0000 Peter Wemm wrote: >The OpenSSL stuff in the FreeBSD source tree has hand-optimized i386 >assembler code in it. The amd64 configuration of the integrated >OpenSSL uses the generic C code. Given this, I wouldn't expect them to >be even close. > > > Is this worth fixing? I could do this: there's no rocket science involved in porting the existing x86 code. The main drawback is maintainability: nobody wants Yet Another Cryptic .S file to maintain. But if the Powers That Be are willing to take an assembly file for these things and it's believed likely to be worthwhile I can take a look. To be honest I'm not sure I'd want to add to the maintainability problem here. The kernel IPsec crypto routines might be a better win, except that nobody has complained about it yet. No way is a .S worth it without complaints. PS. The IP checksum routine is another one that could be improved. It's doing 32 bits at a time right now, with no PREFETCH opcodes.