From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:37147) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RaRiW-0001fn-3g for qemu-devel@nongnu.org; Tue, 13 Dec 2011 07:44:21 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RaRiU-00063f-UB for qemu-devel@nongnu.org; Tue, 13 Dec 2011 07:44:20 -0500 Received: from mout.web.de ([212.227.15.3]:61296) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RaRiU-00063b-I9 for qemu-devel@nongnu.org; Tue, 13 Dec 2011 07:44:18 -0500 Message-ID: <4EE74858.40107@web.de> Date: Tue, 13 Dec 2011 13:43:04 +0100 From: =?UTF-8?B?QW5kcmVhcyBGw6RyYmVy?= MIME-Version: 1.0 References: <1323507747-16261-1-git-send-email-andreas.faerber@web.de> <201112112328.42268.paul@codesourcery.com> <4EE5D9E9.3080700@web.de> <201112121558.44919.paul@codesourcery.com> In-Reply-To: <201112121558.44919.paul@codesourcery.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH 0/4] tcg: Add debug facilities for TCGv List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Paul Brook Cc: Peter Maydell , qemu-devel@nongnu.org Am 12.12.2011 16:58, schrieb Paul Brook: >>> Trying to make a 32-bit target "64-bit safe" without actually >>> implementing the 64-bit target is a complete waste of time. >> >> That's where we disagree. I rather do things right from the start than >> leaving the cleanup work to someone else later on. >> >>> You've almost no chance of getting >>> it right. In some cases the correct answer will be to use 32-bit >>> arithmetic, then sign/zero extend the result. In other cases the correct >>> answer will be to perform word size arithmetic. Blindly picking one >>> just makes the bugs harder to find later. >> >> This series picks nothing blindly. > > Sure it does [snip] No, start by reading the git summary. These four patches don't touch target-* at all. This is intentionally NOT some Coccinelle script running wild doing refactorings. That's what I would call "blindly". > Ther are three ways to resolve a mismatch: > - Change everything to TCGv_i32. > - Change everything to TCGv. > - Add an explicit extension/truncation (compiles to no-op on 32-bit targets). > > There's no way of the developer of a 32-bit architecture to know [snip] Again, that's where we disagree: The whole point of TCGv and tl is to have variable-sized operations scaling with target_long. Thus, using them for fixed-size i32 or i64 operations is a semantic error by definition. Whether or not an i64 target exists. And I certainly don't want to knowingly introduce semantic errors in my new code just so that at another time someone else can use that to review a 64-bit port. That's just plain stupid. As the developer I must know what semantics I am implementing for my target. Note that the three choices are independent of this series, same holds without. The difference is, my series offers a way to *flag* cases where this has been ignored. >> If you have a better proposal how to introduce the checks I want, please >> let us hear it. > I still don't understand how your additional restructions are ever useful. > Please give an example of an actual error your checks will catch. My stated requirement is that I want to detect ALL uses of TCGv_i32 with tl functions and all uses of TCGv with i32 functions, be it an error or a warning. Whether or not such consistency seems useful to you. I have already given four examples to Peter, that you quoted previously. Consider a uint32_t 8-bit status register on a 20-bit architecture - it never scales to i64 so I know that TCGv/tl is definitely wrong! Either point out something that's technically wrong with these patches and I'll gladly fix it, or, again, propose a constructive solution. Reappearing after a year and destructively objecting to patches is something we've been through before. Thanks, Andreas