From owner-cvs-all@FreeBSD.ORG Thu Nov 1 01:56:50 2007 Return-Path: Delivered-To: cvs-all@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2C37A16A421 for ; Thu, 1 Nov 2007 01:56:50 +0000 (UTC) (envelope-from christoph.mallon@gmx.de) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by mx1.freebsd.org (Postfix) with SMTP id 7856513C4BD for ; Thu, 1 Nov 2007 01:56:49 +0000 (UTC) (envelope-from christoph.mallon@gmx.de) Received: (qmail invoked by alias); 01 Nov 2007 01:56:24 -0000 Received: from p54A3EA53.dip.t-dialin.net (EHLO tron.homeunix.org) [84.163.234.83] by mail.gmx.net (mp029) with SMTP; 01 Nov 2007 02:56:24 +0100 X-Authenticated: #1673122 X-Provags-ID: V01U2FsdGVkX185RcZYx5Q5xU26PBEPT8GnsvGAPmYtIQHtMxwnsm UmvcmjZqYHzetr Message-ID: <47293247.7060009@gmx.de> Date: Thu, 01 Nov 2007 02:56:23 +0100 From: Christoph Mallon User-Agent: Thunderbird 2.0.0.6 (X11/20070806) MIME-Version: 1.0 To: Andrey Chernov , Bruce Evans , Christoph Mallon , src-committers@FreeBSD.ORG, cvs-src@FreeBSD.ORG, cvs-all@FreeBSD.ORG References: <200710272232.l9RMWSbK072082@repoman.freebsd.org> <47264710.2000500@gmx.de> <20071101024451.T4289@delplex.bde.org> <20071031223911.GC90994@nagual.pp.ru> In-Reply-To: <20071031223911.GC90994@nagual.pp.ru> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Cc: Subject: Re: cvs commit: src/include _ctype.h X-BeenThere: cvs-all@freebsd.org X-Mailman-Version: 2.1.5 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, 01 Nov 2007 01:56:50 -0000 Andrey Chernov wrote: > On Thu, Nov 01, 2007 at 03:23:56AM +1100, Bruce Evans wrote: >> In fact, one of the cleanups/optimizations in rev.1.5 and 1.6 by ache >> and me was to get rid of the mask. There was already a check for _c >> < 0, so the mask cost even more. The top limit was 256 instead of >> 128, so the point about 8bit immediates didn't apply, but I don't know >> of any machines where the mask is faster (didn't look hard :-). OTOH, >> _c is often a char or a u_char (it is declared as mumble_rune_t, but >> the functions are inline so the compiler can see the original type. >> If _c is u_char and u_char is uint8_t, then (_c < 0 || c >= 256) is >> always false, so the compiler should generate no code for it. The top >> limit of 256 was preferred so that this optimization is possible. A >> top limit of 128 doesn't work so well. > > Please see the tests posted in this thread. Please see my remarks on the tests. Christoph