From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 83352 invoked by alias); 23 Jun 2018 00:24:20 -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 83235 invoked by uid 89); 23 Jun 2018 00:24:04 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=BAYES_00,KAM_SHORT,SPF_HELO_PASS autolearn=ham version=3.3.2 spammy=memories, Reverse, treating X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Sat, 23 Jun 2018 00:24:02 +0000 Received: from smtp.corp.redhat.com (int-mx05.intmail.prod.int.phx2.redhat.com [10.5.11.15]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id DE03E308FB91; Sat, 23 Jun 2018 00:24:00 +0000 (UTC) Received: from redhat.com (ovpn-116-62.phx2.redhat.com [10.3.116.62]) by smtp.corp.redhat.com (Postfix) with ESMTPS id B593861F59; Sat, 23 Jun 2018 00:24:00 +0000 (UTC) Received: from fche by redhat.com with local (Exim 4.89) (envelope-from ) id 1fWWLP-0008Ed-6d; Fri, 22 Jun 2018 20:23:59 -0400 Date: Sat, 23 Jun 2018 00:24:00 -0000 From: "Frank Ch. Eigler" To: Christian Eggers Cc: cgen@sourceware.org Subject: Re: Non-contiguous opcodes Message-ID: <20180623002359.GB11259@redhat.com> References: <2495676.YSRq6Q5dSM@zbook-ubuntu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <2495676.YSRq6Q5dSM@zbook-ubuntu> User-Agent: Mutt/1.5.21 (2010-09-15) X-IsSubscribed: yes X-SW-Source: 2018-q2/txt/msg00004.txt.bz2 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