From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 131039 invoked by alias); 21 Jun 2018 07:29:48 -0000 Mailing-List: contact cgen-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cgen-owner@sourceware.org Received: (qmail 123403 invoked by uid 89); 21 Jun 2018 07:29:45 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.8 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,KAM_SHORT,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.2 spammy=HTo:U*cgen, H*r:sk:cgen@so, H*Ad:U*cgen, dear X-HELO: mout.gmx.net Received: from mout.gmx.net (HELO mout.gmx.net) (212.227.15.18) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Thu, 21 Jun 2018 07:29:43 +0000 Received: from zbook-ubuntu.localnet ([87.163.10.191]) by mail.gmx.com (mrgmx003 [212.227.17.190]) with ESMTPSA (Nemesis) id 0Lvkwm-1gHIWV3Vq0-017Uf1 for ; Thu, 21 Jun 2018 09:29:39 +0200 From: Christian Eggers To: cgen@sourceware.org Subject: Non-contiguous opcodes Date: Thu, 21 Jun 2018 07:29:00 -0000 Message-ID: <2495676.YSRq6Q5dSM@zbook-ubuntu> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-IsSubscribed: yes X-SW-Source: 2018-q2/txt/msg00003.txt.bz2 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