64-bit instruction mask emitting as signed hex value

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

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




Reply | Threaded
Open this post in threaded view
|

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
Reply | Threaded
Open this post in threaded view
|

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

Reply | Threaded
Open this post in threaded view
|

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
>