From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 25302 invoked by alias); 3 Aug 2006 22:08:46 -0000 Received: (qmail 25294 invoked by uid 22791); 3 Aug 2006 22:08:46 -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 22:08:42 +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 k73M8fLh017754; Thu, 3 Aug 2006 18:08:41 -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 k73M8eMF009283; Thu, 3 Aug 2006 18:08:40 -0400 Received: from [172.16.14.227] (IDENT:2+B/39f+r/4vaZ+vH6jQ27eqhTz+A4q9@topaz.toronto.redhat.com [172.16.14.227]) by pobox.toronto.redhat.com (8.12.8/8.12.8) with ESMTP id k73M8eGi006484; Thu, 3 Aug 2006 18:08:40 -0400 Message-ID: <44D273E8.4040006@redhat.com> Date: Thu, 03 Aug 2006 22:08: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> In-Reply-To: <44D270CF.30506@redhat.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: 2006-q3/txt/msg00020.txt.bz2 I forgot to address your other question which was about the difficulty of setting entire_insn before decoding. It's a bit of a chicken and egg situation isnt'y it? You can't set entire insn properly until you know something about the insn, but you can't call decode without setting entire_insn properly. Your method of calling decode twice won't work because of this. Most existing ports determine the insn length by looking at a few bits in base_insn and use this information to fill entire_insn. I'm wondering if the decoder shouldn't be redesigned so that all it takes is base_insn, which should be all that is necessary to identify the insn. The extractors for each format would then read any additional bytes as needed. There is already support for this for ISAs with insns which are longer than an insn word. Dave