From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 101510 invoked by alias); 14 Jun 2016 07:53:09 -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 100368 invoked by uid 89); 14 Jun 2016 07:53:08 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.6 required=5.0 tests=BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=ham version=3.3.2 spammy=H*r:sk:cgen@so, 8th, cgen, encode X-HELO: mail-wm0-f51.google.com Received: from mail-wm0-f51.google.com (HELO mail-wm0-f51.google.com) (74.125.82.51) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-GCM-SHA256 encrypted) ESMTPS; Tue, 14 Jun 2016 07:53:01 +0000 Received: by mail-wm0-f51.google.com with SMTP id v199so108525353wmv.0 for ; Tue, 14 Jun 2016 00:53:01 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=cyH0VeWk7ldK/7Qgz7dOcojVCzENle6New1qgHdVCJQ=; b=DaXmYByDrZmslyOdBMkApIuFNJeN7A7G/WvcwtixAVOPX1ccIk/NeegmWMZxYuo5Fc E9qiOj3NgRdecg8tXtH4WPCZh2yCGv+SUcktAdLRNdmtg1gR790f/qDrpAsZFc77whTi 64EDyxsi+vq/YWKNCf9s6xTNGyeaYmsG/kVDknGFruj45AJUTdrFpGM9S8oH13y4aeFE /BiV7kIah29fcPcx7Dm4cC+UHP+jtZih49x9aVnrMTP0NyPXR1H+FVeD1Ljnt8vepljB OUgEVFih8paJBAqlKp5xye4SaIEABFQwUHZoqVEmtPU/qwnVO2tN+wVbrVAV9smi5FPr GSJg== X-Gm-Message-State: ALyK8tIUgOpB4vvwJjKW6BFkrBZYv6NrbxcrTP0nAInxhUSc90P6xCXP60Q2QzaXqvkY5Q== X-Received: by 10.194.203.105 with SMTP id kp9mr5036488wjc.70.1465890778620; Tue, 14 Jun 2016 00:52:58 -0700 (PDT) Received: from [10.15.38.164] ([92.103.127.250]) by smtp.gmail.com with ESMTPSA id x10sm17879267wjj.14.2016.06.14.00.52.57 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 14 Jun 2016 00:52:57 -0700 (PDT) Subject: Re: sid semantic with derived-operands To: "Frank Ch. Eigler" References: <20160607174504.GD28459@redhat.com> Cc: cgen From: =?UTF-8?Q?Aur=c3=a9lien_Buhrig?= Message-ID: <013634f4-5c36-933b-d993-4136a5dbfd45@gmail.com> Date: Tue, 14 Jun 2016 07:53:00 -0000 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.0 MIME-Version: 1.0 In-Reply-To: <20160607174504.GD28459@redhat.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit X-IsSubscribed: yes X-SW-Source: 2016-q2/txt/msg00013.txt.bz2 Hi, Thank you for your answer and sorry for my late reply. > I have an issue when generating the sid semantic of derived-operands. >> When printing C code for sid semantic, cgen tries to generate a >> hardware index (in /gen-hw-index) from a derived ifield, which is not >> supported by /gen-hw-index. >> [...] > Could you share a relevant usable extract of your .cpu file? > Maybe there is a better way to express what you have in mind. > The cpu file is quite complex. But I think I found why it is not supported. One operand (encoded in a 3-bit ifield) encode a reg file. There are 7 registers & 7 possibles values for this operand. For some insns/opcodes, the 8th encoding is reserved to encode additional operands (exact operand depends on another opcode). Without derived operands, it leads to decode ambiguity. When defining a derived operands with all operands, there are asm/syntax issues, and It seems also decode issue (i looks like the "impossible" 8th value of the reg file is not is correctly decoded and is considered as a valid index for reg file). So I defined a virtual hardware and an associated operand to describe the right operand name for the 8th encoding, with the 7 regs. But this leads to this semantic generation issue ... I finally found a way to make asm, disassembly, sid decode and sid semantic to work by creating one operand & virtual hardware per each ifield encoding. It defines many insns, but there is no more ambiguity. Thank you for your reply, Cheers, Aurélein