From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <cgen-return-2284-listarch-cgen=sources.redhat.com@sourceware.org>
Received: (qmail 1279 invoked by alias); 12 Jul 2009 02:22:51 -0000
Received: (qmail 1267 invoked by uid 22791); 12 Jul 2009 02:22:50 -0000
X-SWARE-Spam-Status: No, hits=-2.3 required=5.0 	tests=AWL,BAYES_00,SPF_HELO_PASS,SPF_PASS
X-Spam-Check-By: sourceware.org
Received: from mx1.redhat.com (HELO mx1.redhat.com) (66.187.233.31)     by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Sun, 12 Jul 2009 02:22:41 +0000
Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) 	by mx1.redhat.com (8.13.8/8.13.8) with ESMTP id n6C2McHd023655; 	Sat, 11 Jul 2009 22:22:38 -0400
Received: from fche.csb (vpn-10-134.bos.redhat.com [10.16.10.134]) 	by int-mx1.corp.redhat.com (8.13.1/8.13.1) with ESMTP id n6C2McVj025059; 	Sat, 11 Jul 2009 22:22:38 -0400
Received: by fche.csb (Postfix, from userid 2569) 	id B84BD58463; Sat, 11 Jul 2009 22:22:37 -0400 (EDT)
To: Doug Evans <dje@sebabeach.org>
Cc: cgen@sourceware.org
Subject: Re: [patch] Hacky fix for -ve shifts in m32r decode2.c for cgen 1.1
References: <20090709214652.B5C876E3D1@sebabeach.org>
From: fche@redhat.com (Frank Ch. Eigler)
Date: Sun, 12 Jul 2009 02:22:00 -0000
In-Reply-To: <20090709214652.B5C876E3D1@sebabeach.org> (Doug Evans's message of "Thu,  9 Jul 2009 14:46:52 -0700 (PDT)")
Message-ID: <y0m4otiy70y.fsf@fche.csb>
User-Agent: Gnus/5.1008 (Gnus v5.10.8) Emacs/21.4 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-IsSubscribed: yes
Mailing-List: contact cgen-help@sourceware.org; run by ezmlm
Precedence: bulk
List-Id: <cgen.sourceware.org>
List-Subscribe: <mailto:cgen-subscribe@sourceware.org>
List-Archive: <http://sourceware.org/ml/cgen/>
List-Post: <mailto:cgen@sourceware.org>
List-Help: <mailto:cgen-help@sourceware.org>, <http://sourceware.org/lists.html#faqs>
Sender: cgen-owner@sourceware.org
X-SW-Source: 2009-q3/txt/msg00018.txt.bz2

Doug Evans <dje@sebabeach.org> writes:

> [...]
> Btw, has the sid m32r simulator been tested recently?

Not as far as I know.

> It's doing things like:
> m32rbf.cxx:
> 	      else // pair of short instructions
> 		{
> 		  UHI first = insn >> 16;
> 		  sem->decode (this, pc, first, first);
> 		}
> and
> m32r-decode.cxx:
>       unsigned int val = (((insn >> 24) & (15 << 4)) | ((insn >> 20) & (15 << 0)));
>       switch (val)
>       {
>       case 0 :
>         entire_insn = entire_insn >> 16;
>
> Note that
> - insn is being shifted by 16 tis and then by 24 bits,

Dunny, maybe this particular switch does not activate in the first
place for 16-bit short instructions?

> - after entire_insn >>= 16, it's been shifted by 32 bits.

(But is the value used after this point?)

- FChE