From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <cgen-return-2132-listarch-cgen=sources.redhat.com@sourceware.org>
Received: (qmail 1661 invoked by alias); 23 Jun 2008 11:08:08 -0000
Received: (qmail 1636 invoked by uid 22791); 23 Jun 2008 11:08:06 -0000
X-Spam-Check-By: sourceware.org
Received: from dns6.french-connexion.com (HELO dns6.french-connexion.com) (66.165.107.194)     by sourceware.org (qpsmtpd/0.31) with ESMTP; Mon, 23 Jun 2008 11:07:36 +0000
Received: (qmail 10400 invoked from network); 23 Jun 2008 13:04:26 +0200
Received: from atuileries-108-1-1-151.w217-128.abo.wanadoo.fr (HELO buhrigD430) (217.128.196.151)   by dns6.french-connexion.com with SMTP; 23 Jun 2008 13:04:26 +0200
From: =?iso-8859-1?Q?Aur=E9lien_Buhrig?= <aurelien.buhrig@tiempo-ic.com>
To: <cgen@sourceware.org>
Subject: sid, base_insn vs entire_insn and ambiguity
Date: Wed, 25 Jun 2008 07:36:00 -0000
Message-ID: <000d01c8d521$6f2fa690$4d8ef3b0$@buhrig@tiempo-ic.com>
MIME-Version: 1.0
Content-Type: text/plain; 	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft Office Outlook 12.0
Content-Language: fr
X-IsSubscribed: yes
Mailing-List: contact cgen-help@sourceware.org; run by ezmlm
Precedence: bulk
List-Id: <cgen.sourceware.org>
List-Subscribe: <mailto:cgen-subscribe@sourceware.org>
List-Archive: <http://sourceware.org/ml/cgen/>
List-Post: <mailto:cgen@sourceware.org>
List-Help: <mailto:cgen-help@sourceware.org>, <http://sourceware.org/lists.html#faqs>
Sender: cgen-owner@sourceware.org
X-SW-Source: 2008-q2/txt/msg00015.txt.bz2

Hello,

I try to port sid simulator for a new  16bit target. This processor have
multiple word insn. (1 or 2 if there is an immediate value). So insn can
take 16 or 32 bits.

So I have the same problem that the one reported here :
http://sourceware.org/ml/cgen/2006-q3/msg00030.html


Since I do not want to do =93some ugly code which examines the base_insn bi=
ts
in order to decide how to position entire_insn=94, and since it seems there=
 is
no new way to have the insn length before decoding the instruction, I tried
the second solution that consists in setting the base-insn-bitsize to 32.

I have now 2 problems :=20
- The disassembly is not correct anymore.
- I have an unresolved ambiguity error.
ERROR: Unable to resolve ambiguity (maybe need some ifield-assertion specs?)

So I tried derived operand with ifield-assertion, the I cannot fix the
ambiguity problem.
Here is the description of the faulty insn:

(define-derived-operand=20=20
  (name unop-pi-pc-imm52)
  (comment "")=20=20
  (attrs)
  (mode UHI)=20
  (args (uimm52) (reg))
  (syntax "$uimm52")
  (base-ifield f-1opopc)
  (encoding (+ UNAD_PI REG_PC uimm52 ) )
  (ifield-assertion (eq f-reg 7))
  (getter (nop))
  (setter (nop)))

(define-derived-operand
  (name unop-pi-gr)
  (comment "")
  (attrs)
  (mode UHI)
  (args (reg))
  (syntax "$(reg)+")
  (base-ifield f-1opopc)
  (encoding (+ UNAD_PI reg ) )
  (ifield-assertion (not (eq f-reg 7)))
  (getter (nop))
  (setter (nop)))

(define-anyof-operand
  (name unop-pi)
  (comment "PI addressing modes")
  (mode UHI)
  (base-ifield f-1opopc)
  (choices unop-pi-pc-imm52 unop-pi-gr))

(dni
      moveps                                                ; name
      (.str mnemonic " (rn)+")                                  ; comment
      ()                                                        ; attrs
      ("move.$len $sr,($reg)+")                                      ;
syntax
      ;+ (+ len SEL_1OP ONEOP_MTSR UNAD_PI reg)             ; format
      (+ len SEL_1OP ONEOP_MTSR unop-pi)                ; format
      (nop)
      ())=20=20=20=20=20


How can I do ?
Thanks,
Aurelien