From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 12319 invoked by alias); 10 Feb 2003 00:56:38 -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 12312 invoked from network); 10 Feb 2003 00:56:37 -0000 Received: from unknown (HELO seba.sebabeach.org) (64.165.110.50) by 172.16.49.205 with SMTP; 10 Feb 2003 00:56:37 -0000 Received: by seba.sebabeach.org (Postfix, from userid 42) id C32E6B539; Sun, 9 Feb 2003 17:05:09 -0800 (PST) From: Doug Evans To: Manuel Kessler Cc: cgen@sources.redhat.com Subject: Re: Again: variable width instructions Message-Id: <20030210010509.C32E6B539@seba.sebabeach.org> Date: Mon, 10 Feb 2003 00:56:00 -0000 X-SW-Source: 2003-q1/txt/msg00040.txt.bz2 Hi. Regarding the fr30 example: ; test file for ldi32 ldi:32 $0x80000000, r0 nop ldi:32 $0x00000000, r1 nop ldi:32 $0xffffffff, r2 nop ldi:32 $0x7fffffff, r3 nop .end 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. :-) 00000000 : 0: 9f 80 00 00 ldi:32 0x0,r0 4: 00 00 0: R_FR30_48 $0x80000000 6: 9f a0 nop 8: 9f 81 00 00 ldi:32 0x0,r1 c: 00 00 8: R_FR30_48 $0x00000000 e: 9f a0 nop 10: 9f 82 00 00 ldi:32 0x0,r2 14: 00 00 10: R_FR30_48 $0xffffffff 16: 9f a0 nop 18: 9f 83 00 00 ldi:32 0x0,r3 1c: 00 00 18: R_FR30_48 $0x7fffffff 1e: 9f a0 nop 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. 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). 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. 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). --- (*1): `df' should actually be the real full form, not an abbreviated form that leaves out the ability to specify things necessary in ciscy ISAs. `dfrf' [define-full-risc-field] or some-such would have been a better choice for the current `df'. (*2): Anyone want to come up with a usable macro who's name is "dunno"? Now that would be funny. :-)