From owner-freebsd-arch@FreeBSD.ORG Wed Feb 27 21:39:15 2013 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 4732CF13 for ; Wed, 27 Feb 2013 21:39:15 +0000 (UTC) (envelope-from christoph.mallon@gmx.de) Received: from mout.gmx.net (mout.gmx.net [212.227.17.21]) by mx1.freebsd.org (Postfix) with ESMTP id 99B22196 for ; Wed, 27 Feb 2013 21:39:14 +0000 (UTC) Received: from mailout-de.gmx.net ([10.1.76.12]) by mrigmx.server.lan (mrigmx002) with ESMTP (Nemesis) id 0LrH2g-1UpXE73dYi-0137rB for ; Wed, 27 Feb 2013 22:39:07 +0100 Received: (qmail invoked by alias); 27 Feb 2013 21:39:03 -0000 Received: from p5B131D5E.dip.t-dialin.net (EHLO rotluchs.lokal) [91.19.29.94] by mail.gmx.net (mp012) with SMTP; 27 Feb 2013 22:39:03 +0100 X-Authenticated: #1673122 X-Provags-ID: V01U2FsdGVkX19CnYUOguZCtaLGJvO1krcmNOtI7Z4VPamnDrloY/ OjZokv9LOe+Xaj Message-ID: <512E7CDA.2020206@gmx.de> Date: Wed, 27 Feb 2013 22:38:34 +0100 From: Christoph Mallon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130222 Thunderbird/17.0.3 MIME-Version: 1.0 To: Pawel Jakub Dawidek Subject: Re: Large Capsicum patch for review. References: <20130213025547.GA2025@garage.freebsd.pl> <20130213230221.GB1375@garage.freebsd.pl> <20130223221116.GR1377@garage.freebsd.pl> <5129ADC5.5040306@gmx.de> <512A2CA0.2050509@gmx.de> <20130224235936.GX1377@garage.freebsd.pl> <512B3DBB.4080909@gmx.de> <20130225215004.GA1375@garage.freebsd.pl> <867glvbbjz.fsf@ds4.des.no> <20130226121345.GB1341@garage.freebsd.pl> In-Reply-To: <20130226121345.GB1341@garage.freebsd.pl> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Y-GMX-Trusted: 0 Cc: =?UTF-8?B?RGFnLUVybGluZyBTbcO4cmdyYXY=?= , freebsd-arch@FreeBSD.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Feb 2013 21:39:15 -0000 On 26.02.2013 13:13, Pawel Jakub Dawidek wrote: > On Tue, Feb 26, 2013 at 11:43:12AM +0100, Dag-Erling Smørgrav wrote: >> Pawel Jakub Dawidek writes: >>> I use size_t as this is preferred type for size, but I don't need size_t >>> for iterator, because I know the value will never need more than 16 >>> bits, so I use int as a more CPU-friendly type. >> >> Using int as an iterator can lead to warnings about signedness mismatch >> in loop conditions etc., so you should at the very least use unsigned >> int. [...] > > I use 'int' for 'ssize_t' and 'unsigned int' for 'size_t'. > >> [...] Besides, size_t is equal to unsigned long on all platforms, so >> "CPU-friendly" is not a valid argument. > > Is long more CPU-friendly than int? Interestingly, yes: 32 bit ints or uints are stored in the lower half of a 64 bit register on AMD64. All 32 bit operations automatically zero extend their result to 64 bits, i.e. the upper half is set to 0. Comparing an uint with size_t can therefore done directly with a 64 bit comparison. But to compare an int with an ssize_t, the int value has to be sign extended to 64 bits. This takes another instruction (movsx) and an extra register to temporarily hold the sign-extended value. On MIPS it's the other way round: 32 bit operations sign extend their result to 64 bits. So comparing int and ssize_t can be done directly and uint+size_t costs another instruction. In summary, mismatched types make the code harder to read and have the potential to force the compiler to produce worse code. Christoph