64-bit instruction mask emitting as signed hex value

64-bit instruction mask emitting as signed hex value

[Brian Mokrzycki]

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

Re: 64-bit instruction mask emitting as signed hex value

[Frank Ch. Eigler]

Hi -

On Mon, Oct 03, 2011 at 09:57:39PM -0500, Brian Mokrzycki wrote:
> [...]

Good hunting!

> Guile 1.6.8
> guile> (number->string 0xFFFFFFFFFFFFFFFF 16) 
> "ffffffffffffffff"
> 
> Guile 1.8.7
> guile> (number->string 0xFFFFFFFFFFFFFFFF 16)
> "-1"

In the case of guile 1.8.8 (fedora 15 x86_64),
and guile 1.8.0 (rhel5 i386),

guile> (number->string 18446744073709551615 16)
"ffffffffffffffff"

Maybe something's wrong just with your build of guile somehow.

- FChE

Re: 64-bit instruction mask emitting as signed hex value

[Brian Mokrzycki]

Interesting.  I'm running Guile 1.8.7 on Mac OS X Lion (10.7) and installed it with MacPorts, the Portfile for guile 1.8.7 at revision 2.  I think the next step is to download the source directly from gnu and see if it was simply a compile option that was missed.

And issuing the identical statement on my installation is

guile> (number->string 18446744073709551615 16)
"-1"

Thanks for the additional clue.

-Brian

On Oct 5, 2011, at 3:34 PM, Frank Ch. Eigler wrote:

> Hi -
> 
> On Mon, Oct 03, 2011 at 09:57:39PM -0500, Brian Mokrzycki wrote:
>> [...]
> 
> Good hunting!
> 
>> Guile 1.6.8
>> guile> (number->string 0xFFFFFFFFFFFFFFFF 16) 
>> "ffffffffffffffff"
>> 
>> Guile 1.8.7
>> guile> (number->string 0xFFFFFFFFFFFFFFFF 16)
>> "-1"
> 
> In the case of guile 1.8.8 (fedora 15 x86_64),
> and guile 1.8.0 (rhel5 i386),
> 
> guile> (number->string 18446744073709551615 16)
> "ffffffffffffffff"
> 
> Maybe something's wrong just with your build of guile somehow.
> 
> - FChE

Re: 64-bit instruction mask emitting as signed hex value

[Brian Mokrzycki]

OK, I only have a fuzzy feeling as to how I got this resolved.  Basically I uninstalled guile from MacPorts and utilized a different portage system (homebrew) to reinstall guile 1.8.7.

During the reinstall homebrew was stating that guile 1.8.7 does not support compilation with LLVM and suggested I switch over to using GCC.  So I did that and now I get the proper behavior

guile> (number->string 0xFFFFFFFFFFFFFFFF 16)
"ffffffffffffffff"

I can't be certain that there wasn't some underlying dependency that was compiled with different configure flags… but I can say "It works" and I can move on to the next issue.

If anyone wants to pipe in and give me a definitive answer I would appreciate it.

Thanks,

-Brian

On Oct 5, 2011, at 3:41 PM, Brian Mokrzycki wrote:

> Interesting.  I'm running Guile 1.8.7 on Mac OS X Lion (10.7) and installed it with MacPorts, the Portfile for guile 1.8.7 at revision 2.  I think the next step is to download the source directly from gnu and see if it was simply a compile option that was missed.
> 
> And issuing the identical statement on my installation is
> 
> guile> (number->string 18446744073709551615 16)
> "-1"
> 
> Thanks for the additional clue.
> 
> -Brian
> 
> On Oct 5, 2011, at 3:34 PM, Frank Ch. Eigler wrote:
> 
>> Hi -
>> 
>> On Mon, Oct 03, 2011 at 09:57:39PM -0500, Brian Mokrzycki wrote:
>>> [...]
>> 
>> Good hunting!
>> 
>>> Guile 1.6.8
>>> guile> (number->string 0xFFFFFFFFFFFFFFFF 16) 
>>> "ffffffffffffffff"
>>> 
>>> Guile 1.8.7
>>> guile> (number->string 0xFFFFFFFFFFFFFFFF 16)
>>> "-1"
>> 
>> In the case of guile 1.8.8 (fedora 15 x86_64),
>> and guile 1.8.0 (rhel5 i386),
>> 
>> guile> (number->string 18446744073709551615 16)
>> "ffffffffffffffff"
>> 
>> Maybe something's wrong just with your build of guile somehow.
>> 
>> - FChE
>