public inbox for cgen@sourceware.org
 help / color / mirror / Atom feed
* Non-contiguous opcodes
@ 2018-06-21  7:29 Christian Eggers
  2018-06-23  0:24 ` Frank Ch. Eigler
  0 siblings, 1 reply; 3+ messages in thread
From: Christian Eggers @ 2018-06-21  7:29 UTC (permalink / raw)
  To: cgen

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

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: Non-contiguous opcodes
  2018-06-21  7:29 Non-contiguous opcodes Christian Eggers
@ 2018-06-23  0:24 ` Frank Ch. Eigler
  2018-06-26  4:24   ` Christian Eggers
  0 siblings, 1 reply; 3+ messages in thread
From: Frank Ch. Eigler @ 2018-06-23  0:24 UTC (permalink / raw)
  To: Christian Eggers; +Cc: cgen

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

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: Non-contiguous opcodes
  2018-06-23  0:24 ` Frank Ch. Eigler
@ 2018-06-26  4:24   ` Christian Eggers
  0 siblings, 0 replies; 3+ messages in thread
From: Christian Eggers @ 2018-06-26  4:24 UTC (permalink / raw)
  To: cgen

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

^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2018-06-26  4:24 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2018-06-21  7:29 Non-contiguous opcodes Christian Eggers
2018-06-23  0:24 ` Frank Ch. Eigler
2018-06-26  4:24   ` Christian Eggers

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).