Re: Again: variable width instructions

[Jan Zizka <janzizka at yahoo dot com>]

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 <test>:
   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 <mlkessle@cip.physik.uni-wuerzburg.de> 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