From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 10216 invoked by alias); 17 Feb 2014 09:11:35 -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 10197 invoked by uid 89); 17 Feb 2014 09:11:33 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.3 required=5.0 tests=AWL,BAYES_00,FREEMAIL_ENVFROM_END_DIGIT,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=ham version=3.3.2 X-HELO: mail-oa0-f66.google.com Received: from mail-oa0-f66.google.com (HELO mail-oa0-f66.google.com) (209.85.219.66) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-SHA encrypted) ESMTPS; Mon, 17 Feb 2014 09:11:32 +0000 Received: by mail-oa0-f66.google.com with SMTP id m1so6047498oag.5 for ; Mon, 17 Feb 2014 01:11:30 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.60.74.105 with SMTP id s9mr861794oev.49.1392628290650; Mon, 17 Feb 2014 01:11:30 -0800 (PST) Received: by 10.182.48.71 with HTTP; Mon, 17 Feb 2014 01:11:30 -0800 (PST) In-Reply-To: References: Date: Mon, 17 Feb 2014 09:11:00 -0000 Message-ID: Subject: Re: Help needed for porting opcodes for CISC architecture From: Usha Gupta To: "Frank Ch. Eigler" Cc: cgen Content-Type: text/plain; charset=ISO-8859-1 X-IsSubscribed: yes X-SW-Source: 2014-q1/txt/msg00005.txt.bz2 Thanks Frank. I have got instructions upto 4 bytes being correctly assembled. I was initially using simplification macro "dnf " for defining instruction fields which does not allows specifying word-length and word-offset. The problem is resolved by specifying instruction fields using define-ifield where I could define the total length of the instruction where this specific instruction field is used . For 5-byte insns, since opcode doesn't fit in CGEN_INSN_INT which is defined in include/opcode/cgen.h as unsigned int , I changed it to "unsigned long long". Is there a cleaner way to achieve this? The instructions seem to get assembled but the bytes are not arranged in the correct order (as defined by the instruction fields used). Say I have an 16-bit unsigned immediate xy and a 8-bit signed immediate n and my instruction format looks like this 0--7 8---------15 16-------23 24--31 32---------39 IIIIIIII yyyyyyyy xxxxxxxx IIIIIIII nnnnnnnn I have defined instruction fields as f-op1- 0,8 (0-7 bits) f-op2 - 24,8 (24-31 bits) f-uimm16 - 8,16 (8-23 bits) f-simm8 - 32,8 (32-39 bits) On seeing the disassembly, I find that both the opcodes are placed contiguously (in 0-15 bits) and also the hi8 of 16-bit unsigned immediate is filled with junk value. Similar issue is seen when 16 bit immediate value is used in 24/32 bit insns. Target is little-endian (in case that matters here). Am I doing something wrong here? > Presumably those IIIII's don't overlap - i.e., the hardware can tell > from the first byte that it's a 2-byte instruction (and more opcode > bits need to be fetched). In cgen, instruction opcodes need not be > single fields nor contiguous; just specify one ifield per unique > opcode piece. Following example shows instruction formats with overlap 1-byte instruction: IIIIIrrr - 5 bits opcode , 3 bits for register operand 2-byte instruction: IIIIIsss IIIIIttt - 5-bit opcode, 3-bit register operand (source), 5-bit opcode, 3-bit register operand (destination) I could not find a common bit pattern to identify the insn length. Can this be handled using CGEN? Thanks in advance. Regards, Usha Gupta