From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 28070 invoked by alias); 9 Jul 2003 19:40:27 -0000 Mailing-List: contact cgen-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cgen-owner@sources.redhat.com Received: (qmail 28040 invoked from network); 9 Jul 2003 19:40:15 -0000 Received: from unknown (HELO touchme.toronto.redhat.com) (216.129.200.2) by sources.redhat.com with SMTP; 9 Jul 2003 19:40:15 -0000 Received: from toenail.toronto.redhat.com (toenail.toronto.redhat.com [172.16.14.211]) by touchme.toronto.redhat.com (Postfix) with ESMTP id 4ED038000DB; Wed, 9 Jul 2003 15:40:14 -0400 (EDT) Received: from toenail.toronto.redhat.com (IDENT:fche@localhost [127.0.0.1]) by toenail.toronto.redhat.com (8.12.8/8.12.5) with ESMTP id h69JeEoM009467; Wed, 9 Jul 2003 15:40:14 -0400 Received: (from fche@localhost) by toenail.toronto.redhat.com (8.12.8/8.12.8/Submit) id h69JeDmj009465; Wed, 9 Jul 2003 15:40:13 -0400 Date: Wed, 09 Jul 2003 19:40:00 -0000 From: "Frank Ch. Eigler" To: Doug Evans Cc: cgen@sources.redhat.com Subject: Re: sid thumb file generation error Message-ID: <20030709194012.GB6861@redhat.com> References: <20030618064201.23BA7B536@mail.sebabeach.org> <20030708163553.0DE46B53A@mail.sebabeach.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030708163553.0DE46B53A@mail.sebabeach.org> User-Agent: Mutt/1.4.1i X-SW-Source: 2003-q3/txt/msg00004.txt.bz2 Hi - > > A related problem was pointed out by a thumb sid user on the net a while > > ago: the sid decoders were confused by the different base-insn-size for > > arm vs thumb. > > For my own education, do you recall what change caused this? > IIRC, the sid arm/thumb simulator was working pretty well in this regard > at one point. I have no direct recollection. Either a sid or a cgen change could have resulted in the base_insn_size interpretation mismatch for the thumb instructions, but there appears to be no relevant sid ChangeLog entry. Anyway, the proposed patch I posted seems to solve the problem in a reasonably elegant way: it lets cgen understand that different ISAs have different base-insn-size units. - FChE