From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1GxPzO-0000aw-5K for qemu-devel@nongnu.org; Thu, 21 Dec 2006 10:37:46 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1GxPzL-0000Zl-RB for qemu-devel@nongnu.org; Thu, 21 Dec 2006 10:37:45 -0500 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1GxPzL-0000Zd-Lt for qemu-devel@nongnu.org; Thu, 21 Dec 2006 10:37:43 -0500 Received: from [193.7.176.60] (helo=mail.bawue.net) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA:32) (Exim 4.52) id 1GxPzL-0008Fj-3z for qemu-devel@nongnu.org; Thu, 21 Dec 2006 10:37:43 -0500 Received: from lagash (p54A47735.dip.t-dialin.net [84.164.119.53]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by mail.bawue.net (Postfix) with ESMTP id 97A29BA6CB for ; Thu, 21 Dec 2006 16:26:50 +0100 (CET) Received: from ths by lagash with local (Exim 4.63) (envelope-from ) id 1GxPpV-0006g1-3g for qemu-devel@nongnu.org; Thu, 21 Dec 2006 15:27:33 +0000 Date: Thu, 21 Dec 2006 15:27:33 +0000 Subject: Re: [Qemu-devel] qemu hw/mips_r4k.c target-mips/cpu.h target-mip... Message-ID: <20061221152732.GD30873@networkno.de> References: <458A57B6.3080901@bellard.org> <20061221113234.GA30873@networkno.de> <2ad73a0612210646q139ef8femf608cd17478b55ed@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable In-Reply-To: <2ad73a0612210646q139ef8femf608cd17478b55ed@mail.gmail.com> From: Thiemo Seufer Reply-To: qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel@nongnu.org Andr=E9 Braga wrote: > On 12/21/06, Thiemo Seufer wrote: > >Fabrice Bellard wrote: > >> You should suppress the SIGN_EXTEND32() macro and just use an 'int32_t' > >> cast... > > > >Then it may not work. A MIPS64 CPU requires properly sign-extended > >32bit values. Host architectures can define either sign- or zero- > >Extension for 32bit values in 64bit Registers. >=20 > Whether or not it works, GCC *WILL* optimize it away as a redundant > statement, Only iff it is redundant, which is what we want to achieve. > if it deems so (i.e., if it's called with some flag that > enables cse/gcse and peephole optimizations, and the variable(s) in > question is(are) not declared volatile). Currently it appears to work as is. Given that the CPU env is a global it is unlikely gcc can use fancy optimizations. When compiling with -combine we may need to declare the emulated machine registers volatile. > IMHO macros like these SHOULD stay, as they are mostly innocuous and > happen to document the target machine behaviour. I disagree, it clutters the source more, and a cast provides the same information. Thiemo