From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 1080 invoked by alias); 27 Mar 2009 14:28:27 -0000 Received: (qmail 1068 invoked by uid 22791); 27 Mar 2009 14:28:25 -0000 X-SWARE-Spam-Status: No, hits=-2.5 required=5.0 tests=AWL,BAYES_00,SPF_PASS X-Spam-Check-By: sourceware.org Received: from smtp-out.google.com (HELO smtp-out.google.com) (216.239.33.17) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Fri, 27 Mar 2009 14:28:20 +0000 Received: from zps19.corp.google.com (zps19.corp.google.com [172.25.146.19]) by smtp-out.google.com with ESMTP id n2REQaT6028900; Fri, 27 Mar 2009 14:26:37 GMT Received: from smtp.corp.google.com (spacemonkey1.corp.google.com [192.168.120.115]) by zps19.corp.google.com with ESMTP id n2REQY3o027419 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 27 Mar 2009 07:26:34 -0700 Received: from localhost.localdomain.google.com (67-218-102-16.cust.layer42.net [67.218.102.16] (may be forged)) (authenticated bits=0) by smtp.corp.google.com (8.13.8/8.13.8) with ESMTP id n2REQP0H011033 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Fri, 27 Mar 2009 06:26:29 -0800 To: daniel tian Cc: gcc@gcc.gnu.org, uday@cse.iitb.ac.in, yxun lan Subject: Re: logical error with 16bit arithmatic operations References: <121fadb80903270212p5ab2c977t86778eed45b94d23@mail.gmail.com> From: Ian Lance Taylor Date: Fri, 27 Mar 2009 18:21:00 -0000 In-Reply-To: <121fadb80903270212p5ab2c977t86778eed45b94d23@mail.gmail.com> (daniel tian's message of "Fri\, 27 Mar 2009 17\:12\:14 +0800") Message-ID: User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-System-Of-Record: true X-IsSubscribed: yes Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org X-SW-Source: 2009-03/txt/msg00817.txt.bz2 daniel tian writes: > I am porting gcc to a 32bit RISC chip, and I met a logical > error with 16bit arithmetic operations in generating assemble code. > the error is between two 16bit data movement(unsigned short). > While like A = B, A, and B are all unsigned short type. B is a > result of a series of computation, which may have value in high 16bit. > Because A , B are both HImode, so the move insn doesn't take zero > extend operation, so A will have value in high 16bit which will caused > a wrong result in computation. The relevant types in your code are "unsigned short". I assume that on your processor that is a 16 bit type. An variable of an unsigned 16 bit type can hold values from 0 to 0xffff, inclusive. There is nothing wrong with having the high bit be set in such a variable. It just means that the value is between 0x8000 and 0xffff. > ;; 1--> 23 R5=R6 0>>0xc :nothing > //R5 and R6 are both unsigned short type. But R6 will > have it's value in high 16bit because of series of logical operations > (AND, OR, XOR and so on). Doing it like this way will cause R5 also > being valued in high 16bit. This will cause a wrong value. The correct > one is : R5 = R2 0 >> 0xC. because R2 did zero extend in former insn >>From R6. But How I let gcc know it. No. 0>> means a logical right shift, not an arithmetic right shift (LSHIFTRT rathre than ASHIFTRT). When doing a logical right shift, the sign bit is moved right also; it is not sticky. This instruction is fine. Perhaps there is a problem in your implementation of LSHIFTRT. Ian