From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 314 invoked by alias); 11 Dec 2002 22:25:06 -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 307 invoked from network); 11 Dec 2002 22:25:06 -0000 Received: from unknown (HELO neon-gw.transmeta.com) (63.209.4.196) by sources.redhat.com with SMTP; 11 Dec 2002 22:25:06 -0000 Received: (from root@localhost) by neon-gw.transmeta.com (8.9.3/8.9.3) id OAA31154; Wed, 11 Dec 2002 14:25:00 -0800 Received: from mailhost.transmeta.com(10.1.1.15) by neon-gw.transmeta.com via smap (V2.1) id xma031141; Wed, 11 Dec 02 14:24:50 -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 gBBMOsR29373; Wed, 11 Dec 2002 14:24:54 -0800 (PST) Received: (from dje@localhost) by xris-athlon.transmeta.com (8.9.3/8.7.3) id OAA27251; Wed, 11 Dec 2002 14:24:54 -0800 From: Doug Evans MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15863.47926.109851.888043@xris-athlon.transmeta.com> Date: Wed, 11 Dec 2002 14:25:00 -0000 To: "Frank Ch. Eigler" Cc: Manuel Kessler , cgen@sources.redhat.com Subject: Re: make CGEN a less moving target? In-Reply-To: <20021211165711.D16403@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> <15863.45845.671543.75854@xris-athlon.transmeta.com> <20021211165711.D16403@redhat.com> X-SW-Source: 2002-q4/txt/msg00078.txt.bz2 Frank Ch. Eigler writes: > dje wrote: > > So how about rephrase it as: > > This is what the h/w first fetches to decode an insn. > > Dunno about that. > > > For non-liw architectures this is the size of the smallest instruction. > > If by "non-liw" you mean "RISC", then all instructions have the same size > and this is trivial. > For variable-length instruction sets, things just seem to work best when > base-insn-size includes all the non-operand bits of the longest instruction. By liw (*1) I mean things like m32r and ia64 (and crusoe! :-). Each instruction (or "molecule") actually contains one or more individual instructions (or "atoms") each executed in parallel. Thus non-liw = the other guys. examples of liw = m32r, ia64, crusoe, examples of non-liw = sparc, mips, ia32, m68k, ppc, yadda yadda yadda For me, for non-liw variable length ISAs, if base-insn-bitsize isn't the length of the smallest insn (*2) then there's a problem. (*1) or epic or vliw or ... Got a prefered term? I've never put much effort into the pedantically correct use of terms. (*2) modulo some weird ISA I'm not aware of