From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 6215 invoked by alias); 26 Oct 2009 12:26:58 -0000 Received: (qmail 6207 invoked by uid 22791); 26 Oct 2009 12:26:57 -0000 X-SWARE-Spam-Status: No, hits=-2.5 required=5.0 tests=AWL,BAYES_00,SPF_PASS X-Spam-Check-By: sourceware.org Received: from mail-fx0-f219.google.com (HELO mail-fx0-f219.google.com) (209.85.220.219) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Mon, 26 Oct 2009 12:26:51 +0000 Received: by fxm19 with SMTP id 19so11810952fxm.26 for ; Mon, 26 Oct 2009 05:26:49 -0700 (PDT) Received: by 10.204.150.69 with SMTP id x5mr4155407bkv.197.1256560009099; Mon, 26 Oct 2009 05:26:49 -0700 (PDT) Received: from ?192.168.2.99? (cpc2-cmbg8-0-0-cust61.cmbg.cable.ntl.com [82.6.108.62]) by mx.google.com with ESMTPS id y15sm8208340fkd.58.2009.10.26.05.26.47 (version=SSLv3 cipher=RC4-MD5); Mon, 26 Oct 2009 05:26:47 -0700 (PDT) Message-ID: <4AE59913.5040402@gmail.com> Date: Mon, 26 Oct 2009 12:26:00 -0000 From: Dave Korn User-Agent: Thunderbird 2.0.0.17 (Windows/20080914) MIME-Version: 1.0 To: Dmitry Eremin-Solenikov CC: cgen Subject: Re: cgen->sim question References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit 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 X-SW-Source: 2009-q4/txt/msg00024.txt.bz2 Dmitry Eremin-Solenikov wrote: > Hello, > > I have a question regarding generating sim code from cgen description. > > I have an instruction operand instantiated from field with type h-addr. > If in the semantics part of the instruction I try to access the operandr > as an address: '(mem QI ddaddr)', I get an error from cgen: > > simplify.inc:131:3: op:new-mode: invalid mode for operand `ddaddr': USI > > This is the definition of ddaddr: > > (dif f-dd-1 "1-byte direct address at 1 position" (ABS-ADDR) 8 8 0 8 UINT #f #f) > (dno ddaddr "direct address" () h-addr f-dd-1) > I've seen this too. I made it go away by changing the hardware element type in the define-normal-operand from h-addr to h-uint (or h-sint in some cases). I don't know for a fact if it was the right thing to do, but all the generated code ended up looking sane; it does leave me a little unsure, however, because now I don't know what h-addr is actually supposed to be used for - my port ends up not using it at all anywhere, and everything appears to work. cheers, DaveK