From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 7856 invoked by alias); 25 Jun 2008 07:36:01 -0000 Received: (qmail 7843 invoked by uid 22791); 25 Jun 2008 07:36:00 -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; Wed, 25 Jun 2008 07:35:40 +0000 Received: (qmail 26150 invoked from network); 25 Jun 2008 09:32:37 +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; 25 Jun 2008 09:32:36 +0200 From: =?iso-8859-1?Q?Aur=E9lien_Buhrig?= To: "'Dave Brolley'" Cc: References: <000d01c8d521$6f2fa690$4d8ef3b0$@buhrig@tiempo-ic.com> <486114F4.1040309@redhat.com> In-Reply-To: <486114F4.1040309@redhat.com> Subject: RE: sid, base_insn vs entire_insn and ambiguity Date: Thu, 26 Jun 2008 09:26:00 -0000 Message-ID: <002001c8d696$303139b0$9093ad10$@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: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cgen-owner@sourceware.org X-SW-Source: 2008-q2/txt/msg00016.txt.bz2 Hi, I succeed in solving the disassembly problem by using "buf" instead of "value" in CGEN_DIS_HASH macro... For the decode, with "base-insn-bitsize 32", the decoding is ok.=20 The only pb is the ambiguity. This ambiguity error only occurs with "base-insn-bitsize 32". With "base-insn-bitsize 16", there is no warning. Let's take an example. add.w csti, @abs16 is encoded the same way than add.w csti, -(rj), but with rj=3DPC and with a second word (the abs16 address) that follows this instruction, (PC is not accessible in the assembly syntax, so add.w csti, -(PC) is forbidden) ------------------------------------------------------------- ; byte/word (bit 0) (dnf f-bw "bit/word selector" () 0 1) ; 2 operands instruction opcode (bits 2-5) (dnf f-2opopc "2 operand opcode" () 2 4) ; Source register (bits 6-8) (dnf f-sreg "Source register" () 6 3) ; 2op addressing mode field (bits 9-12) (dnf f-ad30 "ad[3-0]" () 9 4) ; Destination register (bits 13-15)=20 (dnf f-dreg "Destination register" () 13 3) (define-ifield (name f-abs16) (comment "") (attrs (ABS-ADDR)) (word-offset 16) (word-length 16) (start 0) (length 16) (mode UINT) (encode #f) (decode #f))) (define-normal-insn-enum enum-sel1 "bit 1 sel" () SEL_ f-sel1 ( ("2OP" 1) )) (define-normal-insn-enum enum-2opopc "2 Operand Opcodes" () BINOP_ f-2opopc ( ("ADD" 0) ("ADDC" 1) ("SUB" 2) ("SUBC" 3) ("CMP" 4) ("TB" 5) ("CB" 6) ("SB" 7) ("OR" 7) ("AND" 8) ("XOR" 9) ("MOVEP" 10) ("MOVE" 11) )) (define-normal-insn-enum enum-sreg "sreg enums" () SREG_ f-sreg=20 ( ("R0" 0) ("R1" 1) ("R2" 2) ("R3" 3) ("R4" 4) ("R5" 5) ("SP" 6) ("PC" 7) )) (define-normal-insn-enum enum-ad30 "2op addressing mode" () BINAD_ f-ad30 ( ("CSTIND" 0) ("CSTDRN" 1) ("CSTPI" 2) ("CSTPD" 3) ("CSTAAD" 3) ("RNIND" 4) ("RNDRN" 5) ("RNPI" 6) ("RNPD" 7) ("RNAAD" 7) ("PDRN" 8) ("PIRN" 9) ("DRNRN" 10) ("INDRN" 11) ("AADRN" 12) ("RNRN" 13) ("CSTRN" 14) )) (define-normal-insn-enum enum-dreg "dreg enums" () DREG_ f-dreg ( ("R0" 0) ("R1" 1) ("R2" 2) ("R3" 3) ("R4" 4) ("R5" 5) ("SP" 6) ("PC" 7) )) (define-hardware (name h-gr) (comment "General registers") (type register HI(7)) (indices keyword "" ((sp 6)(r0 0) (r1 1) (r2 2) (r3 3) (r4 4) (r5 5) (r6 6))) (get (index) (c-call HI "@cpu@_h_gr_get_handler" index)) (set (index newval) (c-call VOID "@cpu@_h_gr_set_handler" index newval))) (define-hardware (name h-len) (comment "Instruction length") (type register BI (2)) (indices keyword "" ((b 0) (w 1))) (get (index) (c-call HI "@cpu@_h_len_get_handler" index))) (dnop abs16 "16 bit absolute address" (RELAX) h-iaddr f-abs16) (dnop dreg "Destination register" () h-gr f-dreg) (dnop scst "Source Constant" () h-cst f-sreg) (dnop len "instr len" () h-len f-bw) (define-derived-operand=20 (name binop-aad)=20 (comment "")=20 (attrs)=20 (mode UHI)=20 (args (abs16))=20 (syntax "$abs16")=20 (base-ifield f-2opopc)=20 (encoding (+ BINAD_CSTAAD DREG_PC abs16 ) )=20 (ifield-assertion (eq f-dreg 7))=20 (getter (nop))=20 (setter (nop))) (define-derived-operand=20 (name binop-pd)=20 (comment "")=20 (attrs)=20 (mode UHI)=20 (args (dreg))=20 (syntax "$-(dreg)")=20 (base-ifield f-2opopc)=20 (encoding (+ BINAD_CSTPD dreg ) )=20 (ifield-assertion (not (eq f-dreg 7)))=20 (getter (nop))=20 (setter (nop)))=20 =20 (define-anyof-operand=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20 (name binop-aad-pd)=20 (comment "PD addressing modes")=20 (mode UHI)=20 (base-ifield f-2opopc)=20 (choices binop-aad binop-pd)) (dni (name add-cst) ("add cst -> aadpd") () ("add.$len $scst,${binop-aad-pd}") (+ len SEL_2OP BINOP_ADD scst binop-aad-pd) (nop) ()) ------------------------------------ So the instruction are encoded like that : (+ len 1 0000 scst 0011 dreg) for add.x csti, -(rn) ----- (dreg !=3D 7) (+ len 1 0000 scst 0011 111 abs16) for add.x csti, -(rn) I would like the ifield-assertion differentiates the two instructions, but it fails. Thanks for your help! Aur=E9lien -----Message d'origine----- De=A0: Dave Brolley [mailto:brolley@redhat.com]=20 Envoy=E9=A0: mardi 24 juin 2008 17:38 =C0=A0: Aur=E9lien Buhrig Objet=A0: Re: sid, base_insn vs entire_insn and ambiguity Hi, It's hard to help with this without more complete information. You don't=20 provide the declarations for your ifields or insn enumerations, which=20 could also be the source of the ambiguity. Aur=E9lien Buhrig wrote: > I tried > the second solution that consists in setting the base-insn-bitsize to 32. >=20=20=20 Did you also do the second part of the solution which was to write the=20 necessary code in the decoder (::step_insns in=20 sid/component/cgen-cpu//.cxx) to make sure that both 16 bit=20 and 32 bit insns are aligned in base_insn and entire_insn? i.e., since=20 you don't know whether each insn will be 16 or 32 bits, you need to=20 always read 32 bits: // Fetch 16-bit pieces separately, so endianness // conversions can be done on this chunk size. UHI insn0 =3D this->GETIMEMHI (pc, pc); UHI insn1 =3D this->GETIMEMHI (pc, pc+2); USI insn =3D (insn0 << 16) | insn1; sem->decode (this, pc, insn, insn); > 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: >=20=20=20 It's hard to see what the problem here might be without seeing your=20 ifield and insn enum specs. > (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 > >=20=20=20