Non-contiguous opcodes

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

Non-contiguous opcodes

Christian Eggers
using cgen-1.1

Dear cgen developer(s),

I would like to port GNU binutils for the NXP i.MX SDMA coprocessor
(see https://www.nxp.com/docs/en/reference-manual/IMX6ULRM.pdf,
page 2682 for instruction set).

In contrast to other ISAs found in the cpu files, the SDMA ISA has it's
opcode splitted into several variable length field within a fixed size
16 bit instruction code:

00000jjj00000000  <- opcode @ 15 5, 7 8
00000jjj00000001  <- opcode @ 15 5, 7 8
000000ff00000111  <- opcode @ 15 6, 7 8
10aaaaaaaaaaaaaa  <- opcode @ 15 2
11aaaaaaaaaaaaaa  <- opcode @ 15 2
...

I've tried to solve this with multi-ifields:

(define-normal-ifield f-op15x5      "5 bit opcode field0"                                      
()            15   5)
(define-normal-ifield f-op7x8       "8 bit opcode field3"                                      
()             7   8)

(define-multi-ifield  (name f-op15x5_7x8)  (comment
"done,yield,yieldge,notify,jmpr,jssr,ldrpc,revb,revblo,rorb,ror1,lsr1,asr1,lsl1")
  (attrs)
  (mode UINT)
  (subfields f-op15x5 f-op7x8)
  (insert
    (sequence ()
      (set (ifield f-op15x5) (srl (ifield f-op15x5_7x8) (const 8)))
      (set (ifield f-op7x8)  (and (ifield f-op15x5_7x8) (const #b11111111)))
    )
  )
  (extract
     (sequence ()
       (set (ifield f-op15x5_7x8) (or (sll (zext UHI (ifield f-op15x5)) (const
8)) (zext UHI (ifield f-op7x8))))
     )
  )
)


(define-normal-insn-enum
  opcodes-15x5_7x8 "opcodes" () OP_ f-op15x5_7x8
  (
 ("REVBLO"   #b0000000010001)   ; 00000rrr00010001
...
  )
)

(define-normal-insn
  revblo "Reverse Low Order Bytes" ()
  "revblo $r"
  (+ OP_REVBLO r)
  (set r
    (or (and r #xffff0000)
    (or (sll (and r #x000000ff)  8)
        (srl (and r #x0000ff00)  8)
    ))
  )
  ()
)


Unfortunately, this sdma-opc.c file generated by cgen contains a wrong opcode
value for the REVBLO command:

/* revblo $r */
  {
    { 0, 0, 0, 0 },
    { { MNEM, ' ', OP (R), 0 } },
    & ifmt_asr1, { 0x8811 }   <-- this is xb1000100000010001, but should be
xb0000000000010001
  },

It looks like that lower bits of the opcode enum value (#b0000000010001) are
copied to the first and second subfields of the multi ifield. cgen seems to
ignore the "insert" and "extract" statements, I get the same result when I
simply put

(set (ifield f-op15x5_7x8)  (const 0))

there.

Can I use multi-ifields also for opcodes (not only for additional operators),
or is this not intended by design?

regards
Christian

Reply | Threaded
Open this post in threaded view
|

Re: Non-contiguous opcodes

Frank Ch. Eigler
Hi -

On Thu, Jun 21, 2018 at 09:29:39AM +0200, Christian Eggers wrote:
> [...]
> I would like to port GNU binutils for the NXP i.MX SDMA coprocessor
> (see https://www.nxp.com/docs/en/reference-manual/IMX6ULRM.pdf,
> page 2682 for instruction set).

Neat.

> In contrast to other ISAs found in the cpu files, the SDMA ISA has it's
> opcode splitted into several variable length field within a fixed size
> 16 bit instruction code:
>
> 00000jjj00000000  <- opcode @ 15 5, 7 8
> 00000jjj00000001  <- opcode @ 15 5, 7 8
> 000000ff00000111  <- opcode @ 15 6, 7 8
> 10aaaaaaaaaaaaaa  <- opcode @ 15 2
> 11aaaaaaaaaaaaaa  <- opcode @ 15 2
> ...
>
> I've tried to solve this with multi-ifields:
> [...]

Without digging into the ISA deeply, nor the two-decade-old memories,
have you considered not doing it that way?  Consider instead treating
the opcode-like subfields separately inside the define-normal-insn.
So ditch the single insn-enum as it is, and instead of:

(define-normal-insn
  revblo "Reverse Low Order Bytes" ()
  "revblo $r"
  (+ OP_REVBLO r)
  [...]
)

try:

(define-normal-insn
  revblo "Reverse Low Order Bytes" ()
  "revblo $r"
  (+ (f-op15x5 17) (f-op7x8 0) r)
  [...]
)


- FChE
Reply | Threaded
Open this post in threaded view
|

Re: Non-contiguous opcodes

Christian Eggers
Dear Frank,

Am Samstag, 23. Juni 2018, 02:23:59 CEST schrieb Frank Ch. Eigler:

> Without digging into the ISA deeply, nor the two-decade-old memories,
> have you considered not doing it that way?  Consider instead treating
> the opcode-like subfields separately inside the define-normal-insn.
> So ditch the single insn-enum as it is, and instead of:
>
> (define-normal-insn
>   revblo "Reverse Low Order Bytes" ()
>   "revblo $r"
>   (+ OP_REVBLO r)
>   [...]
> )
>
> try:
>
> (define-normal-insn
>   revblo "Reverse Low Order Bytes" ()
>   "revblo $r"
>   (+ (f-op15x5 17) (f-op7x8 0) r)
>   [...]
> )


I already tried this way and it's working. Perhaps I'll will try to put the
non-contiguous opcode parts into separate enums (similar to fr30.cpu).


BTW: It's some ago seems the last commit into CVS. There may be some items
which should be done (support for newer guile, error messages, ...). Do you
think that cgen should be moved to binutils?

regards
Christian