From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from az33egw02.freescale.net (az33egw02.freescale.net [192.88.158.103]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "az33egw02.freescale.net", Issuer "Thawte Premium Server CA" (verified OK)) by ozlabs.org (Postfix) with ESMTPS id 59DA5B7BEE for ; Sat, 1 May 2010 06:40:30 +1000 (EST) Message-ID: <4BDB402C.9080301@freescale.com> Date: Fri, 30 Apr 2010 15:40:12 -0500 From: Scott Wood MIME-Version: 1.0 To: Timur Tabi Subject: Re: [PATCH 3/5] powerpc/mpc5121: shared DIU framebuffer support References: <1272584978-19063-1-git-send-email-agust@denx.de> <1272584978-19063-4-git-send-email-agust@denx.de> <20100430121947.1d265ca6@wker> <20100430162254.GA24285@schlenkerla.am.freescale.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Cc: linux-fbdev@vger.kernel.org, wd@denx.de, dzu@denx.de, John Rigby , devicetree-discuss@lists.ozlabs.org, linuxppc-dev@ozlabs.org, Anatolij Gustschin , yorksun@freescale.com List-Id: Linux on PowerPC Developers Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Timur Tabi wrote: > On Fri, Apr 30, 2010 at 11:22 AM, Scott Wood wrote: > >>> That's what I meant. Actually, I think it's ULL. Regardless, I think >>> the compiler will see the "1000000000 ... * 1000" and just combine >>> them together. You're not actually outsmarting the compiler. >> The compiler will do no such thing. That's a valid transformation when >> doing pure math, but not when working with integers. > > I ran some tests, and it appears you're right. I doesn't make a lot > of sense to me, but whatever. > > However, "(1000000000 / pixclock) * 1000" produces a result that's > less accurate than "1000000000000ULL / pixclock". Precisely, that's what makes it a distinct computation -- as far as the compiler knows, it could be intentional. Plus, turning it into 64-bit math would invoke a library call for 64-bit division, which wouldn't be much of an optimization anyway. The question is whether the loss of accuracy matters in this case. >>> err = -1; >>> >>> because he wanted it to be the largest possible integer. >> -1 is not the largest possible integer. LONG_MAX, perhaps? > > What, you don't like implicit casting of -1 to an unsigned? :-) I like it even less when the variable is signed and it's still supposed to be larger than positive numbers. :-) -Scott