From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 11025 invoked by alias); 7 Feb 2003 21:06:46 -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 11018 invoked from network); 7 Feb 2003 21:06:45 -0000 Received: from unknown (HELO web41502.mail.yahoo.com) (66.218.93.85) by 172.16.49.205 with SMTP; 7 Feb 2003 21:06:45 -0000 Message-ID: <20030207210644.10389.qmail@web41502.mail.yahoo.com> Received: from [213.243.161.163] by web41502.mail.yahoo.com via HTTP; Fri, 07 Feb 2003 13:06:44 PST Date: Fri, 07 Feb 2003 21:06:00 -0000 From: Jan Zizka Subject: Re: Again: variable width instructions To: cgen@sources.redhat.com In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-SW-Source: 2003-q1/txt/msg00038.txt.bz2 Hi! I had the same problem. I'm porting binutils to DSP56800. Normal instructions have 16bits but eventually this may increase to 48 (3 words). I've solved it by defininig the immediate instruction fields as: (define-ifield (name f-imm16) (comment "16b imm data") (attrs) (word-offset 16) (word-length 16) (start 15) (length 16) (mode UINT) ) (define-ifield (name f-imm16w3) (comment "16b imm data in third word") (attrs) (word-offset 32) (word-length 16) (start 15) (length 16) (mode UINT) ) so when the word-offset is 0 it accesses first 16 bits (I have 16 bit insns base), when it is 16 then the next word etc. You can see the effect on following instructions: (define-pmacro (move18 mnemonic opcode) (dni (.sym "move18-" mnemonic) (.str mnemonic " #imm16,X:imm16") () (.str mnemonic " #$imm16w3,X:$imm16") (+ (f-op-16 opcode) imm16 imm16w3) () () ) ) and example: DSP56800 GAS test16.asm page 1 1 test: 2 0000 E040 nop 3 0001 8504 move a,b 4 0002 86F42000 move #$1000,X:$2000 4 1000 5 0005 81C4FFFF bfclr #$FFFF,A 6 0007 89DE0080 bftstl #128,LC DSP56800 GAS test16.asm page 2 DEFINED SYMBOLS test16.asm:1 .text:00000000 test NO UNDEFINED SYMBOLS and obj dump: a.out: file format elf32-dsp56800 Disassembly of section .text: 00000000 : 0: e0 40 nop 1: 85 04 move A,B 2: 86 f4 20 00 move #0xffff,X:0x1000 4: 10 00 5: 81 c4 ff ff bfclr #0xffff,A 7: 89 de 00 80 bftstl #0x80,LC So this should work also for you :), try it out! At least I hope that this is the effect you want to obtain!? Regards Jan --- Manuel Kessler wrote: > Five or six weeks ago David Carney asked how to handle instructions with > fields beyond the usual instruction size, which is rather CISC-ish. While > Frank and Doug responded quickly, how to handle this situation, by > defining just fields starting at the next bit (and the trick to define > lsb0? to #f), he did not succeed. As he told me, he had to move on to > other things, and so got distracted. > > However, I am in a similar situation, trying to accomplish more or less > the same thing. While for my microcontroller (Mitsubishi M16C, if anybody > is interested) instructions may be as short as 8 bits, with operands, > immediates and prefixes they may grow to up to 80 bits or so. I was able > to assemble and disassemble the first instructions with different > addressing modes (and correspondingly different lengths) by using > xxx-insn-bitsize of 32 (instead of the 8 as suggested in the documentation > for the smallest instruction), but for instructions even longer than that > my attempts were not successful. While I can define instruction fields > that late, I can not fill them with registers or immediates, this data > (register indices etc.) gets stuck in the first portion of the > instruction. > > Doug mentioned the fr30 port as a guidline, which has a single instruction > taking a 32 bit immediate and thus being longer than the others. However, > this functionality seems to be gone. The same problem is there: The > immediate data does not get filled in the appropriate slot. I took this > file: > > ; 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 > > assembled it, and objdump of the result told me: > > a.out: file format elf32-fr30 > > Disassembly of section .text: > > 00000000 <.text>: > in disassemble_bytes > 0: 9f 80 00 00 ldi:32 0x0,r0 > 4: 00 00 > 6: 9f a0 nop > 8: 9f 81 00 00 ldi:32 0x0,r1 > c: 00 00 > e: 9f a0 nop > 10: 9f 82 00 00 ldi:32 0x0,r2 > 14: 00 00 > 16: 9f a0 nop > 18: 9f 83 00 00 ldi:32 0x0,r3 > 1c: 00 00 > 1e: 9f a0 nop > > As you can see, the immediate data vanishes somewhere in between. > > I am kind of stuck now. Is there still a trick I have been missing, or are > variable width instructions currently broken, or only fields beyond the > first instruction portion? > I hope desperately there is a simple fix to this problem. > > Thanks for your time. > > Ciao, > Manuel > > PS: For the curious I have attached the current state of my m16c.cpu > file (I am not sure if it will make it to the list). Feel free to comment > on it, and find further information and a CVS repository of the will-be __________________________________________________ Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now. http://mailplus.yahoo.com