From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 14866 invoked by alias); 3 Aug 2006 21:55:32 -0000 Received: (qmail 14858 invoked by uid 22791); 3 Aug 2006 21:55:31 -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; Thu, 03 Aug 2006 21:55:29 +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 k73LtSmD014611; Thu, 3 Aug 2006 17:55:28 -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 k73LtRx0006471; Thu, 3 Aug 2006 17:55:27 -0400 Received: from [172.16.14.227] (IDENT:MhhC1sMHsQ0eFNuS0JFytNClPvwfBnfg@topaz.toronto.redhat.com [172.16.14.227]) by pobox.toronto.redhat.com (8.12.8/8.12.8) with ESMTP id k73LtRGi005977; Thu, 3 Aug 2006 17:55:27 -0400 Message-ID: <44D270CF.30506@redhat.com> Date: Thu, 03 Aug 2006 21:55: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> In-Reply-To: <44CDF0AC.6070707@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/msg00019.txt.bz2 Ronald Hecht wrote: > Hello again, > > i found another problem in decode. c. As I have variable instruction > size, decode.c does not handle base_insn and insn in the right way. > The file looks like this: > > const IDESC * > proc8bf_decode (SIM_CPU *current_cpu, IADDR pc, > CGEN_INSN_INT base_insn, CGEN_INSN_INT entire_insn, > ARGBUF *abuf) > { > /* Result of decoder. */ > PROC8BF_INSN_TYPE itype; > > { > CGEN_INSN_INT insn = base_insn; > > { > unsigned int val = (((insn >> 0) & (63 << 0))); > switch (val) > { > case 0 : > if ((entire_insn & 0xff) == 0x0) > { itype = PROC8BF_INSN_NOP; goto extract_sfmt_nop; } > itype = PROC8BF_INSN_X_INVALID; goto extract_sfmt_empty; The generated decoder expects base_insn to be the first base-insn-size bits of the insn shifted as far right as possible. What you have specified is correct and the (((insn >> 0) & (63 << 0))) test us correct. It is looking at the low order 6 bits of the base_insn which are the only significant ones (according to your cpu file. The generated decoder expects entire_insn to the all of the insn bits, also shifted as far right as possible. 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