On Saturday 04 September 2010 22:31:45 Cactus wrote: > On Sep 4, 9:34 pm, Cactus <[email protected]> wrote: > > On Sep 4, 9:04 pm, Jason <[email protected]> wrote: > > > On Saturday 28 August 2010 11:56:18 jason wrote: > > > > ----- Original Message ----- > > > > From: "Cactus" <[email protected]> > > > > To: "mpir-devel" <[email protected]> > > > > Sent: Saturday, August 28, 2010 10:27 AM > > > > Subject: [mpir-devel] Re: mingw64 > > > > > > > > On Aug 28, 9:59 am, "jason" <[email protected]> wrote: > > > > > Hi > > > > > > > > > > I think I know why the mingw64 dll builds fail , for multiple > > > > > functions files ie aors_err2_n.asm , in the MSVC build yasm emits > > > > > both functions in a single "unit" , whereas under mingw64 we > > > > > create two links add and sub versions (like we do for unix) , and > > > > > also yasm still emits both functions , so we end up with two > > > > > copys. The same must happen in the static build , but it doesn't > > > > > seem to matter? > > > > > I was planning to get rid of such complications ( or rather move > > > > > them to development machines only , much like autotools generates > > > > > Makefile.in) , a small script should easily take of it. > > > > > > If we do it that way , then the x86_64w asm files with multifunction > > > files ie aors_err1.asm will need to have the same m4 macro's as the > > > linux ones. It's probably easier just to get rid of them altogether > > > (not even a pre-dist stage) For the time being we only need to remove > > > the x86_64 and x86_64w ones , we can leave the other cpu's to later. > > > For x86_64 we only have two of them anyway aors_err1_n and aors_err2_n > > > , and I think x86_64w is the same. Note this still leaves the > > > alternative entry point functions ie addlsh_n and addlsh_nc , but for > > > linux at least this is automatic , and we dont need any configure > > > magic for it.This at least gets us part way towards our goal. > > > > > > > I wwould be very happy to make several changes that are related to > > > > this issue, all of which would make all the Windows builds much > > > > easier: > > > > > > > > 1. All files emit only one routine and only one symbol (this would > > > > expand the source for some 'carry in' and 'no carry in' variants); > > > > ----------------------- > > > > I was hoping to keep files with multiple entry points , but yeah , I > > > > cant see how we can do it in general. For the add_n and add_nc we > > > > could do it with macros , but for the divide it's a bit harder , and > > > > we might need to maintain the function version for full backwards > > > > dll compatibility. -------------- > > > > 2. A strict equality between C and assembler file names and the > > > > symbols they emit (ignoring the prefix); > > > > 3. A new extension (i.e not c, cc, as, asm, ..) for files that are > > > > not compiled directly but are included in other files. > > > > ---------------------- > > > > makes sense > > > > --------------------- > > > > I don't think it matters issuing HAVE_NATIVE defines for all > > > > assembler symbols even if they aare complete C replacements so we > > > > can (I think) ignore this. > > > > ------------------------ > > > > I think we may have to keep some , mainly for those combined > > > > functions that would require temp space if we dont have a native one > > > > ------------------------ > > > > This would allow a major simplification in the Windows builds since > > > > it would then be possible to generate most of the build files > > > > automatically for any Windows build tools. > > > > ----------------------- > > > > yeah > > > > ----------------------- > > > > > > > > > For the t-locale test , is there no way that MSVC will pass it ? , > > > > > if so I'll ifdef it out , with ! _MSC_VER , because under mingw I > > > > > think I can get it to pass , it looks like the redefinition of > > > > > localenv just needs a DECLSPEC > > > > > > > > I haven't tried a DECLSPEC - I see if it works. > > > > > > > > -------------------- > > > > I get a different error message now , it did say something like > > > > declspec doesn't match , I think this is due to my change of config > > > > guess , before I had to force it , and maybe that changed one of the > > > > lib search paths? ----------------------------- > > > > > > > > --------------------------- > > > > > > > > Brian > > > > Hi Jason, > > > > I don't really understand this. > > > > I assumed that we put these into assembler because their speed matters > > but you are now saying we can do without them. > > > > But this doesn't make sense - why did we bother with them in the first > > place? > > > > What is wrong with the two files solution - files for add and subtract > > that use a common include file that contains the 'aors' code? > > > > Brian > > I can see that you have just done this in x86_64 - do you want me to > do it in x86_64w? > > Brian
Yes , cheers , I think we only need the aors_err1_n and aors_err2_n for the moment , ie the ones where we have one piece of source code which generates two pieces of object code , the ones where one piece of source code generates one piece of object code (ie mpn_add_n , mpn_add_nc) but exports two symbols (the entry points) we dont need to do yet to get mingw64 working . Mind you if we want one exported symbol per file , then we have to come up with something in the end.All our current files that export two symbols are all mpn_blah_n and mpn_blah_nc , although I think the division functions could also benefit from this , ie like mpn_divrem_1 and mpn_divrem_1_i where the _i signifys we have a precalculated inverse , and also perhaps mpn_mul_basecase and mpn_addmul_basecase Jason -- You received this message because you are subscribed to the Google Groups "mpir-devel" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/mpir-devel?hl=en.
