From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43)
	id 1GxPC3-0002BT-J0
	for qemu-devel@nongnu.org; Thu, 21 Dec 2006 09:46:47 -0500
Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43)
	id 1GxPC1-00028c-UH
	for qemu-devel@nongnu.org; Thu, 21 Dec 2006 09:46:47 -0500
Received: from [199.232.76.173] (helo=monty-python.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.43) id 1GxPC1-00028O-QA
	for qemu-devel@nongnu.org; Thu, 21 Dec 2006 09:46:45 -0500
Received: from [64.233.184.225] (helo=wr-out-0506.google.com)
	by monty-python.gnu.org with esmtp (Exim 4.52) id 1GxPC1-000577-H3
	for qemu-devel@nongnu.org; Thu, 21 Dec 2006 09:46:45 -0500
Received: by wr-out-0506.google.com with SMTP id i11so1120264wra
	for <qemu-devel@nongnu.org>; Thu, 21 Dec 2006 06:46:44 -0800 (PST)
Message-ID: <2ad73a0612210646q139ef8femf608cd17478b55ed@mail.gmail.com>
Date: Thu, 21 Dec 2006 12:46:43 -0200
From: "=?ISO-8859-1?Q?Andr=E9_Braga?=" <meianoite@gmail.com>
Subject: Re: [Qemu-devel] qemu hw/mips_r4k.c target-mips/cpu.h target-mip...
In-Reply-To: <20061221113234.GA30873@networkno.de>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
References: <E1GxCbE-0000Xp-GU@savannah.gnu.org> <458A57B6.3080901@bellard.org>
	<20061221113234.GA30873@networkno.de>
Reply-To: qemu-devel@nongnu.org
List-Id: qemu-devel.nongnu.org
List-Unsubscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.gnu.org/pipermail/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: qemu-devel@nongnu.org

On 12/21/06, Thiemo Seufer <ths@networkno.de> 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.

Whether or not it works, GCC *WILL* optimize it away as a redundant
statement, 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).

IMHO macros like these SHOULD stay, as they are mostly innocuous and
happen to document the target machine behaviour.



Cheers,
A.