I finally got fat binary support working for x86_64 and I've committed
it to trunk.
There were heaps of problems. The most severe and difficult to find
was an incorrect function declaration in one of the files which has
probably been there since we started. Anyhow it now builds, and I
didn't need any peculiar hacks to make it work properly (as if fat
binary support for x86 wasn't already a hack).
Bill.
2009/1/26 Bill Hart <goodwillh...@googlemail.com>:
> I finally got it to run some of the tests without segfaulting. For
> some reason putting the offset into the cpuvec into rax and using that
> as an offset didn't seem to work.
>
> Now things are vaguely working except that the cpuvec isn't populating
> properly. This is because one needs fallback .c files in
> mpn/x86_64/fat for all the functions that are fat functions (for x86
> or x86_64) but not implemented in assembly in x86_64. But if one adds
> such fallback files, one gets "conflicting declaration" errors due to
> gmp-impl.h not knowing they were fat functions.
>
> This is because OPERATION_mpn_blah was not defined for each function.
> Basically somehow yasm is supposed to define this symbol for everyone
> else. But yasm doesn't have that functionality as far as I know. It
> seems that because gcc is used to build the .asm files that these can
> be defined somehow for the .asm files.
>
> Haven't thought of a solution for this yet.
>
> Bill.
>
> 2009/1/26 Bill Hart <goodwillh...@googlemail.com>:
>> 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
-~----------~----~----~----~------~----~------~--~---
