Although this is certainly going to be a problem (rdx is used for
passing parameters), changing rdx to some other register does not fix
the problem.
Still baffled!!
Bill.
2009/1/26 Bill Hart <goodwillh...@googlemail.com>:
> Hmm, it just occurred to me that rdx, rbx and rax are stuffed up by
> this procedure. So before the function is called, any parameters in
> those registers will get wiped. That's probably the problem! The
> registers that are used for passing parameters on x86_64 must be
> different than those used on x86_32.
>
> Bill.
>
> 2009/1/26 Bill Hart <goodwillh...@googlemail.com>:
>> I've been looking into the problem with mpn/x86_64/fat/fat_entry.asm
>>
>> I misunderstood how this works. The macro FAT_ENTRY defines functions
>> such as __gmpn_add_n, etc. All this function does is jump to the
>> address in the cpuvec_t (assuming these have been set up).
>>
>> Initially however, the addresses in the cpuvec_t are set to point to
>> functions of the form __gmpn_add_n_init. Each such function is defined
>> by the macro FAT_INIT (also in the file fat_entry.asm). Each of these
>> init functions simply calls CPUID and figures out which version of the
>> relevant function is the right one for that processor, e.g.
>> __gmpn_add_n_amd64 or __gmpn_add_n_core2, etc. It places the pointer
>> to the correct function into the cpuvec_t then jumps to that function.
>>
>> So when external code first calls __gmpn_add_n, it looks in the
>> cpuvec_t and finds a pointer to __gmpn_add_n_init which detects the
>> CPU and places the correct function pointer into the cpuvec_t for next
>> time. Then it jumps to that pointer and executes the real mpn_add_n
>> function.
>>
>> The next time external code calls __gmpn_add_n, the right function
>> pointer is already there, so it just jumps straight to that.
>>
>> Now here's the thing. If I remove the "jump to address listed in the
>> cpuvec_t" and just have it return instead, in the __gmpn_blah_n_init
>> functions (by changing the FAT_INIT macro), then the test code no
>> longer segfaults (though it does of course fail).
>>
>> But here is what happens in that instance. The test code calls
>> __gmpn_add_n. This looks in the cpuvec_t and jumps to the function
>> pointer listed there. But this is the a pointer to the function
>> __gmpn_add_n_init. That function puts the "correct" address in the
>> cpuvec_t, which it then doesn't call (because I modified it to return
>> instead). So absolutely everything works without segfault, except
>> calling the real mpn_add_n function.
>>
>> But that means that there can only be two possibilities. Either the
>> address of the real mpn_add_n function is computed incorrectly, or
>> there is something wrong with the real mpn_add_n function. The latter
>> seem unlikely given that it works for a non-fat build. So somehow
>> computing the address is incorrect.
>>
>> But the function which stuffs this address into the cpuvec_t is
>> __gmpn_cpuvec_init. Specifically it calls a macro such as
>> CPUVEC_SETUP_amd64 (depending on the architecture detected by the
>> CPUID - which I have verified works).
>>
>> But here is that MACRO:
>>
>> #define CPUVEC_SETUP_amd64 \
>> do { \
>> decided_cpuvec.mul_karatsuba_threshold = 29; \
>> decided_cpuvec.mul_toom3_threshold = 137; \
>> decided_cpuvec.sqr_karatsuba_threshold = 62; \
>> decided_cpuvec.sqr_toom3_threshold = 186; \
>> decided_cpuvec.add_n = __gmpn_add_n_amd64; \
>> decided_cpuvec.addmul_1 = __gmpn_addmul_1_amd64; \
>> decided_cpuvec.copyd = __gmpn_copyd_amd64; \
>> decided_cpuvec.copyi = __gmpn_copyi_amd64; \
>> decided_cpuvec.mul_basecase = __gmpn_mul_basecase_amd64; \
>> decided_cpuvec.sqr_basecase = __gmpn_sqr_basecase_amd64; \
>> decided_cpuvec.sub_n = __gmpn_sub_n_amd64; \
>> decided_cpuvec.submul_1 = __gmpn_submul_1_amd64; \
>> } while (0)
>>
>> Not much can go wrong there. Note decided_cpuvec is local to
>> __gmpn_cpuvec_init, but at the end of the function it copies
>> everything over into the cpuvec_t actually used by the function calls
>> (spoken about above).
>>
>> So in short. I have no frigging clue why the code doesn't work!
>>
>> Bill.
>>
>> 2009/1/19 Bill Hart <goodwillh...@googlemail.com>:
>>> For the time being I'll just assume that config.guess will return
>>> mingw64 instead of mingw32. If that is not the case, we can make it so
>>> when you figure out how to tell.
>>>
>>> Bill.
>>>
>>> 2009/1/19 mabshoff <michael.absh...@mathematik.uni-dortmund.de>:
>>>>
>>>>
>>>>
>>>> On Jan 19, 5:45 am, "Case Vanhorsen" <cas...@gmail.com> wrote:
>>>>> On 1/19/09, Bill Hart <goodwillh...@googlemail.com> wrote:
>>>>>
>>>>>
>>>>>
>>>>> > Hi Case,
>>>>
>>>> Hi,
>>>>
>>>>> > can you run ./config.guess for us on your machine (it is in the main
>>>>> > directory of the source tree for MPIR). You may need to set
>>>>> > permissions first by doing chmod 755 config.guess
>>>>>
>>>>> $ ./config.guess
>>>>> core2-pc-mingw32
>>>>>
>>>>> > You're right. It isn't fully figuring out that it needs to be doing 32
>>>>> > bit assembly on this machine. Probably we need to recognise that it is
>>>>> > mingw and force it to use ABI=32 throughout.
>>>>
>>>> Note that Mingw has a 64 bit port, so the assumption Mingw -> 32 bit
>>>> build no longer holds. Unfortunately I am not sure how to properly
>>>> identify a 64 bit MinGW build. If I find out I will let yo know since
>>>> I have meant to start playing with it more for a while.
>>>>
>>>>> > Bill.
>>>>
>>>> Cheers,
>>>>
>>>> Michael
>>>>
>>>> <SNIP>
>>>>
>>>> >>>>
>>>>
>>>
>>
>
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"mpir-devel" group.
To post to this group, send email to mpir-devel@googlegroups.com
To unsubscribe from this group, send email to
mpir-devel+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/mpir-devel?hl=en
-~----------~----~----~----~------~----~------~--~---
