From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 25423 invoked by alias); 14 Aug 2006 20:34:13 -0000 Received: (qmail 25414 invoked by uid 22791); 14 Aug 2006 20:34:12 -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, 14 Aug 2006 20:34:09 +0000 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.11.20060308/8.12.11) with ESMTP id k7EKY7Pk017709; Mon, 14 Aug 2006 16:34:07 -0400 Received: from pobox.toronto.redhat.com (pobox.toronto.redhat.com [172.16.14.4]) by int-mx1.corp.redhat.com (8.12.11.20060308/8.12.11) with ESMTP id k7EKY2IP017814; Mon, 14 Aug 2006 16:34:02 -0400 Received: from [172.16.14.227] (IDENT:6DZWkkPXclN8/585sJQYxULGvJuBNrss@topaz.toronto.redhat.com [172.16.14.227]) by pobox.toronto.redhat.com (8.12.8/8.12.8) with ESMTP id k7EKY10F030087; Mon, 14 Aug 2006 16:34:01 -0400 Message-ID: <44E0DE39.9090702@redhat.com> Date: Mon, 14 Aug 2006 20:34:00 -0000 From: Dave Brolley User-Agent: Mozilla Thunderbird 1.0.2 (X11/20050317) MIME-Version: 1.0 To: Ronald Hecht CC: cgen@sourceware.org Subject: Re: Simulator: base_insn and insn in decode.c References: <44CDF0AC.6070707@uni-rostock.de> <44D270CF.30506@redhat.com> <44D30B5A.6070304@uni-rostock.de> In-Reply-To: <44D30B5A.6070304@uni-rostock.de> 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: 2006-q3/txt/msg00028.txt.bz2 I've been on vacation.... Ronald Hecht wrote: >> The test around the goto is intended to make sure that the untested >> base_insn bits are as expected. It needs to be there, otherwise, >> invalid insns get recognized as valid ones. However, it would seem >> that the test should be against base_insn and not against >> entire_insn. I'll have a look at some other cgen simulators, >> including those which use SID to make sure that this assertion holds >> water. It probably hasn't come up until now, since most sims I have >> seen are able to pass the same value for base_insn and entire_insn. >> >> Dave >> > > > I agreee. The test should be against base_insn. But then it still > seems to be double-checking against the same, or not? No it's not a redundant test. The decoder only tests enough bits in the switch to uniquely separate the valid insns. There may be invalid bit patterns (i.e. unused opcodes) that still match. The secondary test makes sure that *all* of the opcode bits in the insn are tested. Dave