64-bit instruction mask emitting as signed hex value

[Brian Mokrzycki <brian-mokrzycki@uiowa.edu>]

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 throughout this port, but have run into a snag.  I pulled down version 2.21 of binutils, applied my changes, and then pulled down the latest snapshot of CGEN (20110901).  I noticed in the processor specific generated files, specifically the opcodes/wvfe-opc.c that the generated bit mask is wrong. For instance,

static const CGEN_IFMT ifmt_cnop ATTRIBUTE_UNUSED = {
  6, 6, 0x-1, { { F (F_63_6) }, { 0 } }
};

The emitted bit mask is actually the signed representation of what should be 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.scm.  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).  Shown 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 = {\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"))
)

……….

(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 insn
                                "0 }")
                   "")
               " }")
)

So I decided to run a little test between guile 1.8.7 and guile 1.6.8, to see if there was some issue there.

Guile 1.6.8
guile> (number->string 0xFFFFFFFFFFFFFFFF 16) 
"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 there a simple fix that I can add to cgen/opc-itab.scm to circumvent this issue?  I searched for a while to see if there was a way I could type cast 0xFFFFFFFFFFFFFFFF to an unsigned value with no luck.

Thanks,

-Brian Mokrzycki