From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 2368 invoked by alias); 11 Dec 2002 10:39: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 2360 invoked from network); 11 Dec 2002 10:39:09 -0000 Received: from unknown (HELO wrzx35.rz.uni-wuerzburg.de) (132.187.3.35) by sources.redhat.com with SMTP; 11 Dec 2002 10:39:09 -0000 Received: from wrzx30.rz.uni-wuerzburg.de (wrzx30.rz.uni-wuerzburg.de [132.187.1.30]) by wrzx35.rz.uni-wuerzburg.de (8.8.8/8.8.8/uniwue-MM-1.05) with ESMTP id LAA22521 for ; Wed, 11 Dec 2002 11:39:07 +0100 (MET) Received: from localhost (localhost [127.0.0.1]) by virusscan.rz.uni-wuerzburg.de (Postfix) with ESMTP id 2D39744667 for ; Wed, 11 Dec 2002 11:39:07 +0100 (CET) Received: from wrzx07.rz.uni-wuerzburg.de (wrzx07.rz.uni-wuerzburg.de [132.187.1.7]) by wrzx30.rz.uni-wuerzburg.de (Postfix) with ESMTP id 0A8384441F for ; Wed, 11 Dec 2002 11:39:07 +0100 (CET) Received: from spamchecker (localhost [127.0.0.1]) by spamcheck.rz.uni-wuerzburg.de (Postfix) with ESMTP id 198384648 for ; Wed, 11 Dec 2002 11:39:06 +0100 (CET) Received: from wpax16.physik.uni-wuerzburg.de (wpax16.physik.uni-wuerzburg.de [132.187.42.16]) by wrzx07.rz.uni-wuerzburg.de (Postfix) with ESMTP id E83B4933 for ; Wed, 11 Dec 2002 11:39:05 +0100 (CET) Received: from localhost (mlkessle@localhost) by wpax16.physik.uni-wuerzburg.de (8.10.0/8.10.0) with ESMTP id gBBAdUm23789 for ; Wed, 11 Dec 2002 11:39:31 +0100 (MET) Date: Wed, 11 Dec 2002 02:39:00 -0000 From: Manuel Kessler X-Sender: mlkessle@wpax16.physik.uni-wuerzburg.de To: cgen@sources.redhat.com Subject: Re: make CGEN a less moving target? In-Reply-To: <15862.9492.864974.265990@xris-athlon.transmeta.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-13.1 required=8.0 tests=CARRIAGE_RETURNS,IN_REP_TO,LOCAL_CLIENT,LOCAL_SENDER, NICE_HELO,QUOTED_EMAIL_TEXT,SPAM_PHRASE_02_03, USER_AGENT_PINE version=2.43-string_20021002 X-Spam-Level: X-Virus-Scanned: by AMaViS snapshot-20020422 X-SW-Source: 2002-q4/txt/msg00067.txt.bz2 Hello list, 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). You may find it, if interested, at http://savannah.nongnu.org/projects/m16c/. Unfortunately, it is a quite CISC like architecture, for which support in CGEN is, uhhm, improvable. No offense intended certainly. Probably part of my problem is a lack of decent fluency in Scheme, but I promise to better myself. On Tue, 10 Dec 2002, Doug Evans wrote: [...] > > - I've always wanted to be able to handle the x86 ISA better. > [and ciscy isa's in general] > [...] 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. After some problems with my own M16C port when defining non-contiguous fields (define-multi-ifield) I tried the ia32.cpu description and got the same error as in my case: ERROR: In procedure map: ERROR: Argument out of range: (0 0 2 5) As said before, I am not (yet) capable of interpreting this error correctly, 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? 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. So 8 should be a reasonable value. However, many instructions are 16 bits or longer. Therefore I have to spefify several instruction fields (for example a second operand field) with bit numbers above 8. Will CGEN detect such cases and behave properly? Well, I tried and it does generate some code, but as I am not yet at the stage of building a complete application as gas or objdump, I can't really tell whether the result is correct. 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), as described in the manual, section 3.15 (Modes). However, this was rejected as "mode AI not supported". Is this just an oversight, not supported or am I simply off track here? For now, I replaced it with SI and mask the superfluous bits, but AI would be more descriptive and accurate. 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. Clear? Is there any chance to specify this addressing-fiddling with prefixes in CGEN? Thank you very much for this fine piece of software and of course for reading down this far, considering my sort of newbie questions. Ciao, Manuel PS: Oh well, I am using snapshot-20023011, and yes, I have read the manual several times.