Re: 2.6.0 built for win32 but using 64-bit limbs

65 views
Skip to first unread message

Cactus

unread,
Jan 14, 2013, 4:44:44 PM1/14/13
to mpir-...@googlegroups.com
On Monday, 14 January 2013 18:37:16 UTC, MJ Michaels wrote:
Is it possible to configure the VC10 build in MPIR 2.6.0 to generate 64-bit limbs?  I am able to do this, but have to edit mpir.h by hand to get it to work, and I'm wondering if there's just some build option that I'm missing.  I basically just remove references to "#ifdef _WIN64".  Is there a reason why this is a bad idea?
Thanks in advance.
Mj Michaels

Unfortunately there is no standard Visual Studio build that does what you want.   As you found, MPIR on Windows is set up to use 32-bit limbs on win32 and 64-bit limbs on x64.

Using 64-bit limbs on win32 is likely to work for the generic C version of MPIR but it will fail for all the assembler based builds since all the x86 assembler code assumes that limbs are 32-bits.

So its certainly not a good idea unless you limit yourself to the generic C build.  And here, of course, you are on your own since it is not a tested configuration.

       Brian

MJ Michaels

unread,
Jan 14, 2013, 5:25:11 PM1/14/13
to mpir-...@googlegroups.com
Thanks for the answer Brian. My problem is that I have code on all other platforms that passes an int64 to mpz_set_ui(), but on Windows this doesn't work. I could fix this by turning the int64 into two int32's and calling mpz_set_ui() appropriately with those values. Or I can use the generic C build with 64-bit limbs. Do you have thoughts about which is the better approach?
Thanks.
Mj

Cactus

unread,
Jan 14, 2013, 5:55:31 PM1/14/13
to mpir-...@googlegroups.com
If you have to work on win32, my advice would be to write a small routine (as you suggest) that uses mpz_set_ui() to (1) shift the int64 right 32-bits and load the result into an mpz, (2) shift the mpz left 32-bits, and (3) add the low 32-bits of the int64 to it.   This is much safer than playing with mpir.h and the cost in performance will be very small and will be more than offset by being able to use the assembler optimised MPIR versions.

    Brian

Brian Gladman

unread,
Jan 14, 2013, 6:18:53 PM1/14/13
to mpir-...@googlegroups.com
On 14/01/2013 22:25, MJ Michaels wrote:

[snip]
>> So its certainly not a good idea unless you limit yourself to the generic C build. And here, of course, you are on your own since it is not a tested configuration.
>
> Thanks for the answer Brian. My problem is that I have code on all other platforms that passes an int64 to mpz_set_ui(), but on Windows this doesn't work. I could fix this by turning the int64 into two int32's and calling mpz_set_ui() appropriately with those values. Or I can use the generic C build with 64-bit limbs. Do you have thoughts about which is the better approach?
> Thanks.

I forgot to mention that the problem with mpz_set_ui() on win32 has
nothing to do with the internal limb size used by MPIR. The MPIR 'ui'
interface on win32 uses unsigned ints and these are 32-bits on Windows.

To change this you don't need to change the limb size - what you need to
change the single typedef for mpir_ui so that it becomes an 'unsigned
long long' on Windows (maybe also change mpir_si to 'signed long long'
as well). This will leave the limb size unchanged so you can use the x86
assembler code.

The other option you have is to use the mpz_set_ux() instead of
mpz_set_ui() since uintmax_t is 64-bits on Windows even on win32. And
this is available 'out of the box'.

Brian

Mj Michaels

unread,
Jan 30, 2013, 2:42:19 PM1/30/13
to mpir-...@googlegroups.com
Hi Brian - Things were going pretty well for me, but I just discovered a problem.  I need to be able to serialize an mpz_t value and pass it between platforms where the size of limbs is not the same.  For example, I need to take a byte stream representing a serialized mpz_t with 64-bit words, and read it on win32 into an mpz_t that is 32 bit words.  Am I out of luck?  I was hoping that mpz_import() would do the trick, since it takes a size value, but this didn't just work.  Should it?  Are there any other tricks up your sleeve for this?
Mj


--
You received this message because you are subscribed to the Google Groups "mpir-devel" group.
To post to this group, send email to mpir-...@googlegroups.com.
To unsubscribe from this group, send email to mpir-devel+...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/mpir-devel?hl=en.


Brian Gladman

unread,
Jan 30, 2013, 5:21:43 PM1/30/13
to mpir-...@googlegroups.com, Mj Michaels
On 30/01/2013 19:42, Mj Michaels wrote:
> Hi Brian - Things were going pretty well for me, but I just discovered a
> problem. I need to be able to serialize an mpz_t value and pass it
> between platforms where the size of limbs is not the same. For example,
> I need to take a byte stream representing a serialized mpz_t with 64-bit
> words, and read it on win32 into an mpz_t that is 32 bit words. Am I
> out of luck? I was hoping that mpz_import() would do the trick, since
> it takes a size value, but this didn't just work. Should it? Are there
> any other tricks up your sleeve for this?

The input and export functions should do this - if you can offer a
simple example that fails, I can take a look at it.

Brian

Brian Gladman

unread,
Jan 30, 2013, 5:36:59 PM1/30/13
to mpir-...@googlegroups.com
On 30/01/2013 19:42, Mj Michaels wrote:
> Hi Brian - Things were going pretty well for me, but I just discovered a
> problem. I need to be able to serialize an mpz_t value and pass it
> between platforms where the size of limbs is not the same. For example,
> I need to take a byte stream representing a serialized mpz_t with 64-bit
> words, and read it on win32 into an mpz_t that is 32 bit words. Am I
> out of luck? I was hoping that mpz_import() would do the trick, since
> it takes a size value, but this didn't just work. Should it? Are there
> any other tricks up your sleeve for this?

Can you say how it failed?

I would be inclined to start with the simplest possible import/export
using bytes:

mpz_export(buf, *count, 1, 1, 0, 0, mpz)

and:

mpz_import(mpz, count, 1, 1, 0, 0, buf)

Since it seems that the length of the data (i.e. count) has to be input,
you need to recover this in some way on export so it can be used on import.

Using bytes avoids a lot of issues with byte order and should work. If
it doesn't, I suspect something is broken.

Brian

Mj Michaels

unread,
Jan 31, 2013, 8:46:23 AM1/31/13
to mpir-...@googlegroups.com
So sorry - user error on my part.  It works like a champ!
M.


  Brian

--
You received this message because you are subscribed to the Google Groups "mpir-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email to mpir-devel+...@googlegroups.com.

To post to this group, send email to mpir-...@googlegroups.com.
Reply all
Reply to author
Forward
0 new messages