From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 10732 invoked by alias); 27 Jun 2008 08:33:40 -0000 Received: (qmail 10718 invoked by uid 22791); 27 Jun 2008 08:33:39 -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; Fri, 27 Jun 2008 08:33:18 +0000 Received: (qmail 21032 invoked from network); 27 Jun 2008 10:30:07 +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; 27 Jun 2008 10:30:06 +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> <002001c8d696$303139b0$9093ad10$@buhrig@tiempo-ic.com> <002701c8d76e$b8cce7f0$2a66b7d0$@buhrig@tiempo-ic.com> <002801c8d79d$701c0160$50540420$@buhrig@tiempo-ic.com> <4863C118.5080807@redhat.com> In-Reply-To: <4863C118.5080807@redhat.com> Subject: RE: sid, base_insn vs entire_insn and ambiguity Date: Fri, 27 Jun 2008 16:02:00 -0000 Message-ID: <002c01c8d830$91078c80$b316a580$@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/msg00020.txt.bz2 I do have ifield-assertion on conflicting operand. (one is set to (eq dreg 7) and the other to (ne dreg 7) ) =09 So it seem some fields are not correctly set or are lost somewhere... I cannot see the generated code since the generation is aborted before printing the decode function. How can I debug or help debugging ? Aurelien -----Message d'origine----- De=A0: Dave Brolley [mailto:brolley@redhat.com]=20 Envoy=E9=A0: jeudi 26 juin 2008 18:17 =C0=A0: Aur=E9lien Buhrig Cc=A0: cgen@sourceware.org Objet=A0: Re: sid, base_insn vs entire_insn and ambiguity If you got the message "Unable to resolve ambiguity", then at least one=20 of the conflicting insns did not have an ifield assertion. Otherwise=20 CGEN should go on to generate the decoder switch entry. Did you check=20 the generated code to see if that happened? Looking at the=20 insn-base-mask for add-cst-binop-pd, I suspect that it may not have an=20 ifield assertion for bits 13-15. Dave Aur=E9lien Buhrig wrote: > Humm... it seems the problem was not fixed... > Don't know why I has passed once, but after a whole cleanup of the build > directory, I cannot get rid of the ambiguity error. > > In interactive mode, the output is : > -------------------------------------------------- > Building subtable at index 1027, decode-bitsize =3D 16, indices used thus far: > 1 2 3 4 5 7 8 9 10 11 12 > Best decode bits (prev=3D(1 2 3 4 5 7 8 9 10 11 12 ) start=3D0 decode=3D16)=3D>((13 > 14 15 )) > insn =3Dadd-cst-binop-pd insn-value=3D4018 insn-base-mask=3D7c78 insn-len= =3D16 > decode-len=3D3 opcode=3D0 opcode-mask=3D0 indices=3D(0 4 2 6 1 5 3 7 ) > insn =3Dadd-cst-binop-aad insn-value=3D401f0000 insn-base-mask=3D7c7f0000 > insn-len=3D32 decode-len=3D3 opcode=3D7 opcode-mask=3D7 indices=3D(0 ) > Processing decoder for bits 13 14 15 ... > Processing decode entry 0 in decode_table_1027_0, add.${len} > ${scst},-($dreg) ... > Processing decode entry 1 in decode_table_1027_1, add.${len} > ${scst},-($dreg) ... > Processing decode entry 2 in decode_table_1027_2, add.${len} > ${scst},-($dreg) ... > Processing decode entry 3 in decode_table_1027_3, add.${len} > ${scst},-($dreg) ... > Processing decode entry 4 in decode_table_1027_4, add.${len} > ${scst},-($dreg) ... > Processing decode entry 5 in decode_table_1027_5, add.${len} > ${scst},-($dreg) ... > Processing decode entry 6 in decode_table_1027_6, add.${len} > ${scst},-($dreg) ... > Processing decode entry 7 in decode_table_1027_7, subtable ... > Building subtable at index 7, decode-bitsize =3D 16, indices used thus fa= r: 13 > 14 15 1 2 3 4 5 7 8 9 10 11 12 > -population-top-few: count-threshold is zero! > Best decode bits (prev=3D(13 14 15 1 2 3 4 5 7 8 9 10 11 12 ) start=3D0 > decode=3D16)=3D>(()) > -population-top-few: count-threshold is zero! > Best decode bits (prev=3D(13 14 15 1 2 3 4 5 7 8 9 10 11 12 ) start=3D16 > decode=3D0)=3D>(()) > Filtering 2 instructions for non specializations. > WARNING: Decoder ambiguity detected: add-cst-binop-aad, add-cst-binop-pd > Filtering 2 instructions for identical variants. > ----------------------------------------------------- > > Since applying add-cst-binop-pd mask on both add-cst-binop-pd and > add-cst-binop-add insn gives the same result, I understand there is an > ambiguity. > > > But looking a bit deeper into the code (decode.scm), there is this comment : > ; FIXME: For now we assume that if they all have an > ; ifield-assertion spec, then there is no ambiguity (it's left > ; to the programmer to get it right). This can be made more > ; clever later. > > Since there IS ifield-assertion, why this ambiguity is not resolved ??? > I can print backtrace if it helps... > > Thanks > Aur=E9lien > > > -----Message d'origine----- > De : cgen-owner@sourceware.org [mailto:cgen-owner@sourceware.org] De la part > de Aur=E9lien Buhrig > Envoy=E9 : jeudi 26 juin 2008 11:26 > =C0 : cgen@sourceware.org > Objet : RE: sid, base_insn vs entire_insn and ambiguity > > It seems I solved the problem replacing (not (eq ..)) by (ne ...) in the > ifield-assertion. > Sorry about that! > > Aur=E9lien > > > -----Message d'origine----- > De : cgen-owner@sourceware.org [mailto:cgen-owner@sourceware.org] De la part > de Aur=E9lien Buhrig > Envoy=E9 : mercredi 25 juin 2008 09:36 > =C0 : 'Dave Brolley' > Cc : cgen@sourceware.org > Objet : RE: sid, base_insn vs entire_insn and ambiguity > > 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=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 : Dave Brolley [mailto:brolley@redhat.com]=20 > Envoy=E9 : mardi 24 juin 2008 17:38 > =C0 : Aur=E9lien Buhrig > Objet : 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: >=20=20=20 >> I tried >> the second solution that consists in setting the base-insn-bitsize to 32. >>=20=20=20 >>=20=20=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); >=20=20=20 >> 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 >>=20=20=20=20=20 > specs?) >=20=20=20 >> 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 >>=20=20=20=20=20 > It's hard to see what the problem here might be without seeing your=20 > ifield and insn enum specs. >=20=20=20 >> (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 >>=20=20=20=20=20 > >=20=20=20