From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 5219 invoked by alias); 11 Feb 2003 13:42:00 -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 5188 invoked from network); 11 Feb 2003 13:42:00 -0000 Received: from unknown (HELO wrzx35.rz.uni-wuerzburg.de) (132.187.3.35) by 172.16.49.205 with SMTP; 11 Feb 2003 13:42:00 -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 OAA198550 for ; Tue, 11 Feb 2003 14:41:59 +0100 (CET) Received: from virusscan (localhost [127.0.0.1]) by wrzx30.rz.uni-wuerzburg.de (Postfix) with ESMTP id 16B4A44FA6 for ; Tue, 11 Feb 2003 14:41:59 +0100 (CET) Received: from wrzx37.rz.uni-wuerzburg.de ([132.187.3.37]) by virusscan (wrzx30 [132.187.1.30:25]) (amavisd-new) with ESMTP id 05224-04 for ; Tue, 11 Feb 2003 14:41:58 +0100 (CET) Received: from spamchecker (localhost [127.0.0.1]) by wrzx37.rz.uni-wuerzburg.de (Postfix) with ESMTP id E52F6AADE for ; Tue, 11 Feb 2003 14:41:57 +0100 (CET) Received: from wpax16.physik.uni-wuerzburg.de (wpax16.physik.uni-wuerzburg.de [132.187.42.16]) by wrzx37.rz.uni-wuerzburg.de (Postfix) with ESMTP id C44BEA319 for ; Tue, 11 Feb 2003 14:41:57 +0100 (CET) Received: from localhost (mlkessle@localhost) by wpax16.physik.uni-wuerzburg.de (8.10.0/8.10.0) with ESMTP id h1BDgRQ21010 for ; Tue, 11 Feb 2003 14:42:27 +0100 (MET) Date: Tue, 11 Feb 2003 13:42:00 -0000 From: Manuel Kessler X-Sender: mlkessle@wpax16.physik.uni-wuerzburg.de To: cgen@sources.redhat.com Subject: Re: Again: variable width instructions In-Reply-To: <20030210010509.C32E6B539@seba.sebabeach.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-13.4 required=8.0 tests=CARRIAGE_RETURNS,IN_REP_TO,LOCAL_CLIENT,LOCAL_SENDER, NICE_HELO,QUOTED_EMAIL_TEXT,SPAM_PHRASE_01_02, USER_AGENT_PINE version=2.43-string_20021002 X-Spam-Level: X-Virus-Scanned: by amavisd-new (Rechenzentrum Universitaet Wuerzburg) X-SW-Source: 2003-q1/txt/msg00041.txt.bz2 Thanks first to Doug and Jan for their helpful comments. On Sun, 9 Feb 2003, Doug Evans wrote: > Things might actually be working ok, depending upon whether or not > $0x80000000, etc. are valid symbols. What's happening is that > gas is interpreting them as symbols ($ doesn't prefix constants in > fr30 assembler). If you had included -r in the arguments to objdump > you would have seen the following. Live and learn I guess. :-) Feeling a little embarrassed, but who knows fr30 assembler anyway ;-) > Regarding problems specifying ciscy fields in m16c.cpu, Jan is right. > You (probably) want to use the full form of define-ifield for these. > It's unfortunate that I didn't create a shorthand version of the > full form of define-ifield, I think its absence has led to some confusion. > E.g. You don't need #lsb0 = #f, it just makes the abbreviated short forms > dnf and df [sic (*1)] work better. Yes, I have been playing with lsb0=#t and #f, and I think there is some problem with #t, possibly only in combination with little endian. Attached you will find my updated m16c.cpu file, which nearly works with xxx-insn-bitsize 16. As I need constant fields in the second byte, I probably cannot go down to 8 currently, but that's ok for me now. For testing, I defined some ifields with the full form, especially take a look at f-opc1b, which is an opcode part in the second byte. If I define it with word-offset 8 and start 5, the opcode part (0x2f) does not end up in the corresponding bits of the second byte, but gets added to the first byte! However, if I define it with word-offset 0 and start 13, the behaviour is correct?!? Interestingly enough, the nearly identical definition of the register part in the second byte (which is obviously not constant, but depends on the chosen register) is working both ways. To make matters worse, in one combination of lsb0, word-offset and xxx-bitsize (can't remember exactly, and am too lazy to reproduce, so feel very free to ignore this paragraph), the assembled bytes were correct, but objdump couldn't disassemble them back, so some information was included in the assembler, but missing in the disassembler or vice versa. Anyway, there is a way to do it, so it's okay. The problem occurs if I go to the variant including 8bit displacement, which is 24bit long (negi8). If I leave the displacement field out (disp8), the two opcodes in the first two bytes get assembled correctly, but naturally the displacement is missing. If I include the displacement field in the instruction definition, the displacement gets filled in the correct place and the next instruction starts at the correct position 24bits later, but the two opcode bytes get screwed up. More specifically, the opcode part which belongs to bits 0-6 (lsb0=#t) of the second byte, vanishes completely, as do bits 6-7 of the first byte, and bits 4-5 of the first byte show up in their proper positions in the second byte. So that's the current state of affairs. Feel free again to comment on the attached m16c.cpu file. > I went to savannah.nongnu.org and checked out and built an m16c toolchain > (but using the m16c.cpu file you included in your message). Thank you very much for getting this far! > I can see some of the problems you're having. For example, > > neg.b 4[a0] > > disassembles to > > 0: a2 2f 04 42 *unknown* > > but it's only a 3 byte insn. It is clear that any unknown instruction gets disassebled as base-insn-bitsize, but if it gets disassembled, then with the proper length. > You really do want to use the proper values of 8 for base-insn-size, etc. > > (default-insn-bitsize 8) > (base-insn-bitsize 8) > (default-insn-word-bitsize ???) > > Off the top of my head I dunno what's a good value for > default-insn-word-bitsize for the m16c. > > Given that base-insn-bitsize is 8 you'll want to use the full form of > define-ifield, or the macros that are in your m16.cpu file: dif and dnif (*2). > > There's one more problem though. Cgen current doesn't support ifields > with constant values beyond base-insn-size. There are hooks for this > in various places, but no one has finished the work. It's straightforward, > more leg-work than brain-work. I'll make a point of getting to it > this week (can't promise an ETA, but we shall see). Of course I do want the correct xxx-bitsize, but as I need the constant ifields beyond 8 bits I (currently, at least) have little choice. 16 would be fine, if I can make it work. Thanks again for all the help up to now, but gratefuls as I am I will still beg for more :-) Ciao, Manuel ______________________________________________________________________ Dr. Manuel Kessler, Dipl.-Phys. Institut fuer Aerodynamik und Gasdynamik Universitaet Stuttgart Pfaffenwaldring 21 ( ( ( ( ___________.^.___________ ) ) ) ) 70550 Stuttgart / Germany _\I/_ /\_|_/\ Phone: +49 711 685 3435 \_(_)_/ Fax: +49 711 685 3438 ./ \. E-Mail: kessler@iag.uni-stuttgart.de WWW: http://www.iag.uni-stuttgart.de/people/manuel.kessler ______________________________________________________________________