From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 31101 invoked by alias); 5 Dec 2005 17:11:27 -0000 Received: (qmail 31091 invoked by uid 22791); 5 Dec 2005 17:11:26 -0000 X-Spam-Check-By: sourceware.org Received: from mx1.redhat.com (HELO mx1.redhat.com) (66.187.233.31) by sourceware.org (qpsmtpd/0.31) with ESMTP; Mon, 05 Dec 2005 17:11:25 +0000 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.11/8.12.11) with ESMTP id jB5HBMFh007042; Mon, 5 Dec 2005 12:11:22 -0500 Received: from pobox.toronto.redhat.com (pobox.toronto.redhat.com [172.16.14.4]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id jB5HBHV09018; Mon, 5 Dec 2005 12:11:17 -0500 Received: from [172.16.14.227] (IDENT:t0C4Abp62nWh4BIjdn7a+lqMyZKRNFLu@topaz.toronto.redhat.com [172.16.14.227]) by pobox.toronto.redhat.com (8.12.8/8.12.8) with ESMTP id jB5HBCbs008436; Mon, 5 Dec 2005 12:11:17 -0500 Message-ID: <439474B0.4000806@redhat.com> Date: Mon, 05 Dec 2005 17:11:00 -0000 From: Dave Brolley User-Agent: Mozilla Thunderbird 1.0.2 (X11/20050317) MIME-Version: 1.0 To: Hans-Peter Nilsson CC: cgen@sourceware.org Subject: Re: Unbreak CRIS sim: fix -gen-decode-insn-entry. And why the widened mem fetch? References: <200512050130.jB51UttW013171@ignucius.se.axis.com> In-Reply-To: <200512050130.jB51UttW013171@ignucius.se.axis.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-IsSubscribed: yes Mailing-List: contact cgen-help@sourceware.org; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cgen-owner@sourceware.org X-SW-Source: 2005-q4/txt/msg00049.txt.bz2 Hans-Peter Nilsson wrote: >>Date: Fri, 02 Dec 2005 14:13:26 -0500 >>From: Dave Brolley >> >> >>The switch generator stops when it has tested enough bits to resolve >>ambiguity among the defined insns, but since it wasn't going on to test >>the remaining bits, the decoder was recognizing invalid insns as valid. >>This additional test goes on to test all the fixed bits in each insn to >>ensure that they are all correct. >> >> > >I assume you mean with opcode definitions for > >opcode= >0?0 >1?0 > >(where opcode & 2 is don't care and opcode & 1 is invalid) >that there was *before* the extra generated code, only a test >generated for (opcode & 4) and that there's *now* (opcode & 5) >== 4 and (opcode & 5) == 0, with 1 and 5 flagged as invalid >insns; not that you mean that there are now checks for (opcode & >7) == 0 and (opcode & 7) == 4. > > Correct. Dave