From owner-svn-src-head@FreeBSD.ORG Wed Mar 21 08:58:45 2012 Return-Path: Delivered-To: svn-src-head@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 9ABB6106566C; Wed, 21 Mar 2012 08:58:45 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from mail08.syd.optusnet.com.au (mail08.syd.optusnet.com.au [211.29.132.189]) by mx1.freebsd.org (Postfix) with ESMTP id 28D988FC14; Wed, 21 Mar 2012 08:58:44 +0000 (UTC) Received: from c211-30-171-136.carlnfd1.nsw.optusnet.com.au (c211-30-171-136.carlnfd1.nsw.optusnet.com.au [211.30.171.136]) by mail08.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id q2L8wfNt008137 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 21 Mar 2012 19:58:42 +1100 Date: Wed, 21 Mar 2012 19:58:41 +1100 (EST) From: Bruce Evans X-X-Sender: bde@besplex.bde.org To: Tijl Coosemans In-Reply-To: <201203210930.58389.tijl@freebsd.org> Message-ID: <20120321194833.W1116@besplex.bde.org> References: <201203091148.q29BmuIp005151@svn.freebsd.org> <201203201519.12926.tijl@freebsd.org> <201203201456.14375.jhb@freebsd.org> <201203210930.58389.tijl@freebsd.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: svn-src-head@FreeBSD.org, svn-src-all@FreeBSD.org, src-committers@FreeBSD.org, John Baldwin Subject: Re: svn commit: r232721 - head/sys/x86/include X-BeenThere: svn-src-head@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SVN commit messages for the src tree for head/-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Mar 2012 08:58:45 -0000 On Wed, 21 Mar 2012, Tijl Coosemans wrote: > On Tuesday 20 March 2012 19:56:14 John Baldwin wrote: >> On Tuesday, March 20, 2012 10:19:07 am Tijl Coosemans wrote: >... >>> No, on i386 bswap64 with a variable argument currently expands to two >>> bswap instructions. With your change it would be many shifts and logical >>> operations. The _gen variants are more like fallback implementations. >>> If bswapNN cannot be implemented directly it is split up. If those >>> smaller problems can be implemented directly, good, if not split it up >>> again and so on. >> >> Oh, I now parse the comment in __bswap64_var() correctly. That's fugly. >> >> Still, it seems that if I keep the patch to port this to ia64 (so it >> can do constants as constants), then it will need to use this approach >> since it won't have the i386 problem (in its case the _gen variants >> are only used for constants). > > Maybe name them _const then as on other architectures. But we hoped to to use the "generic" version on all arches, with only 1 definition for it, and nothing MD except possibly the "var" version. The "constant" version was renamed because it isn't limited to constants. I think it was changed to call the general version (above the "generic" version) after that, since it would have made no sense for the "constant" version to call a non-"constant" version. The "generic" version isn't really generic, since it only works for parameters without side effects. This is arranged by the "var" versions copying the parameters to non-volatile variables and then applying either the "generic" version or asm. Bruce