From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 11772 invoked by alias); 11 Dec 2002 12:18:11 -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 11765 invoked from network); 11 Dec 2002 12:18:08 -0000 Received: from unknown (HELO touchme.toronto.redhat.com) (216.138.202.10) by sources.redhat.com with SMTP; 11 Dec 2002 12:18:08 -0000 Received: from tooth.toronto.redhat.com (tooth.toronto.redhat.com [172.16.14.29]) by touchme.toronto.redhat.com (Postfix) with ESMTP id 68DD1800087; Wed, 11 Dec 2002 07:18:08 -0500 (EST) Received: from tooth.toronto.redhat.com (IDENT:MbGTIIA04NyJefvYuH+qHs56QMZdhrVA@localhost [127.0.0.1]) by tooth.toronto.redhat.com (8.12.5/8.12.5) with ESMTP id gBBCI8jD007748; Wed, 11 Dec 2002 07:18:08 -0500 Received: (from fche@localhost) by tooth.toronto.redhat.com (8.12.5/8.12.5/Submit) id gBBCI7Zp007746; Wed, 11 Dec 2002 07:18:07 -0500 Date: Wed, 11 Dec 2002 04:18:00 -0000 From: "Frank Ch. Eigler" To: Manuel Kessler Cc: cgen@sources.redhat.com Subject: Re: make CGEN a less moving target? Message-ID: <20021211121807.GA7339@redhat.com> References: <15862.9492.864974.265990@xris-athlon.transmeta.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4i X-SW-Source: 2002-q4/txt/msg00068.txt.bz2 Hi - On Wed, Dec 11, 2002 at 11:39:29AM +0100, Manuel Kessler wrote: > [...] > I am quite new to CGEN and started to write a new port of GNU binutils > (and later on gdb, gcc, ???) for the Mitsubishi M16C family of > microcontrollers (together with others, of course). [...] Great! > Is "better" the correct term here? Or is x86 supposed to be working (at > least the partially implemented add instruction) at all, or to be seen as > how to do a CISC example? All other cpus are more RISC like. The x86.cpu file is, as far as I know, only meant as an example. I believe actual generation of opcodes or simulators was never attempted. > [...] > but it seems to me that non-contiguous ifields are currently > not really supported. Is this correct, or how can I achieve the desired > effect? Depending on whether these ifields contain operands or opcode constants, different tricks may be necessary. But CGEN can handle several varieties of non-contiguous ifields. > I am not quite sure how to correctly set the different *-bitsize values in > define-isa. The architecture is 16 bits (little endian), but the smallest > instruction is 8 bits long. [...] 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. Having real instructions that are shorter than that is not a problem. > [...] > A more minor point: The architecture features some address registers, > which may be 16 or 24 bits wide, depending on the model, otherwise being > 16 bit. Therefore I tried to describe these in define-hardware as of mode > AI (address integer) [... but that broke ...] Right, some of these logical types are not usable everywhere, sometimes for odd reasons. Consider using HI or SI, depending on architecture. (It would sure be nice to generalize CGEN's type system to represent N-bit types.) > Finally: The architecture allows additional indirect addressing by using a > special prefix byte, i.e. if you want to negate a register, you write > neg.w r0 > but if you want to negate the memory value pointed to by the register > neg.w [r0] > the same opcode is used, prefixed by an additional byte marking the > indirect addressing of the following instruction. [...] One way to model this would be to consider the prefix byte part of the opcode of the indirect-addressing variant of the instruction. (You would probably use a macro to generate the two variants.) Other ways likely include too much fiddling with C/C++ runtime flags and handmade parsers. - FChE