From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 9704 invoked by alias); 11 Dec 2002 21:50:29 -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 9695 invoked from network); 11 Dec 2002 21:50:28 -0000 Received: from unknown (HELO neon-gw.transmeta.com) (63.209.4.196) by sources.redhat.com with SMTP; 11 Dec 2002 21:50:28 -0000 Received: (from root@localhost) by neon-gw.transmeta.com (8.9.3/8.9.3) id NAA28615; Wed, 11 Dec 2002 13:50:23 -0800 Received: from mailhost.transmeta.com(10.1.1.15) by neon-gw.transmeta.com via smap (V2.1) id xma028584; Wed, 11 Dec 02 13:50:10 -0800 Received: from xris-athlon.transmeta.com (xris-athlon.transmeta.com [10.10.25.96]) by deepthought.transmeta.com (8.11.6/8.11.6) with ESMTP id gBBLoDR26461; Wed, 11 Dec 2002 13:50:13 -0800 (PST) Received: (from dje@localhost) by xris-athlon.transmeta.com (8.9.3/8.7.3) id NAA27171; Wed, 11 Dec 2002 13:50:13 -0800 From: Doug Evans MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15863.45845.671543.75854@xris-athlon.transmeta.com> Date: Wed, 11 Dec 2002 13:50:00 -0000 To: "Frank Ch. Eigler" Cc: Manuel Kessler , cgen@sources.redhat.com Subject: Re: make CGEN a less moving target? In-Reply-To: <20021211164238.C16403@redhat.com> References: <15862.9492.864974.265990@xris-athlon.transmeta.com> <20021211121807.GA7339@redhat.com> <15863.44987.69574.486620@xris-athlon.transmeta.com> <20021211164238.C16403@redhat.com> X-SW-Source: 2002-q4/txt/msg00076.txt.bz2 Frank Ch. Eigler writes: > Hi - > > > > The most important value is the base-insn-size. This should be > > > large enough to include all opcode-like bits in the longest > > > instruction, so most likely 16 or even 32 for this chip. [...] > > > > If the definition of base-insn-size has been changed to this that's a bummer. > > When did this go in? > > I believe this is a practical description of what actually tends > to work with the opcodes/sim/sid runtimes, and does not relate to > any recent patches. So how about rephrase it as: This is what the h/w first fetches to decode an insn. For non-liw architectures this is the size of the smallest instruction.