From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 19693 invoked by alias); 4 Oct 2011 02:57:58 -0000 Received: (qmail 19676 invoked by uid 22791); 4 Oct 2011 02:57:57 -0000 X-SWARE-Spam-Status: No, hits=-2.6 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,T_TO_NO_BRKTS_FREEMAIL X-Spam-Check-By: sourceware.org Received: from mail-gy0-f169.google.com (HELO mail-gy0-f169.google.com) (209.85.160.169) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 04 Oct 2011 02:57:43 +0000 Received: by gya6 with SMTP id 6so55014gya.0 for ; Mon, 03 Oct 2011 19:57:42 -0700 (PDT) Received: by 10.151.28.19 with SMTP id f19mr727650ybj.151.1317697062636; Mon, 03 Oct 2011 19:57:42 -0700 (PDT) Received: from [10.0.1.201] (173-17-40-74.client.mchsi.com. [173.17.40.74]) by mx.google.com with ESMTPS id r12sm7916525anm.13.2011.10.03.19.57.40 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 03 Oct 2011 19:57:41 -0700 (PDT) From: Brian Mokrzycki Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Subject: 64-bit instruction mask emitting as signed hex value Date: Tue, 04 Oct 2011 02:57:00 -0000 Message-Id: <857E14BA-89BB-47E3-8BC9-CC02F296787F@uiowa.edu> To: cgen@sourceware.org Mime-Version: 1.0 (Apple Message framework v1244.3) 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: 2011-q4/txt/msg00001.txt.bz2 Hi all, I've finally got around to updating a home grown processor (wvfe) port of = binutils from 2.19 to 2.21. I'm hoping to clean up several things througho= ut this port, but have run into a snag. I pulled down version 2.21 of binu= tils, applied my changes, and then pulled down the latest snapshot of CGEN = (20110901). I noticed in the processor specific generated files, specifica= lly the opcodes/wvfe-opc.c that the generated bit mask is wrong. For instan= ce, static const CGEN_IFMT ifmt_cnop ATTRIBUTE_UNUSED =3D { 6, 6, 0x-1, { { F (F_63_6) }, { 0 } } }; The emitted bit mask is actually the signed representation of what should b= e there, namely a 64-bit word of 0xFFFFFFFFFFFFFFFF. So I decided to do a = bit more digging and found the offending scheme source in cgen/opc-itab.sc= m. Please note that I had to change this code a bit in my previous port (2= .19) to get the unsigned long long 64-bit word support ("ULL" added). Show= n with my changes cgen/opc-itab.scm: (define (/gen-ifmt-table-1 ifmt) (gen-obj-sanitize (ifmt-eg-insn ifmt) ; sanitize based on the example insn (string-list "static const CGEN_IFMT " (gen-sym ifmt) " ATTRIBUTE_UNUSED =3D {\n" " " (number->string (ifmt-mask-length ifmt)) ", " (number->string (ifmt-length ifmt)) ", " ; Long instruction support, by BTM ; WAS: "0x" (number->string (ifmt-mask ifmt) 16) ", " "0x" (number->string (ifmt-mask ifmt) 16) "ULL, " "{ " (string-list-map (lambda (ifld) (string-list "{ F (" (ifld-enum ifld #f) ") }, ")) (ifmt-ifields ifmt)) "{ 0 } }\n};\n\n")) ) =85=85=85. (define (gen-ivalue-entry insn) (string-list "{ " ; Long instruction support, by BTM ; WAS: "0x" (number->string (insn-value insn) 16) "0x" (number->string (insn-value insn) 16) "ULL" (if #f ; (ifmt-opcodes-beyond-base? (insn-ifmt insn)) (string-list ", { " ; ??? wip: opcode values beyond the base in= sn "0 }") "") " }") ) So I decided to run a little test between guile 1.8.7 and guile 1.6.8, to s= ee if there was some issue there. Guile 1.6.8 guile> (number->string 0xFFFFFFFFFFFFFFFF 16)=20 "ffffffffffffffff" Guile 1.8.7 guile> (number->string 0xFFFFFFFFFFFFFFFF 16) "-1" That test explained why my bit masks we're messed up. So is this a bug with guile version 1.6.8 or guile version 1.8.6?? and is t= here a simple fix that I can add to cgen/opc-itab.scm to circumvent this is= sue? I searched for a while to see if there was a way I could type cast 0x= FFFFFFFFFFFFFFFF to an unsigned value with no luck. Thanks, -Brian Mokrzycki