Hi Brian, With regards to the rename to mpir, I have thought and thought about it, and I simply do not know of a way of doing it in linux. Michael says he knows, but I think I am going to have to leave this one up to him. He is the only one with sufficient experience to sort this out. It might even prove impossible for him due to some unforeseen quirks of GMP and the autotools.
At the moment I strongly urge that we don't rename the linux binaries and includes to mpir for now. It certainly won't affect Sage and I think we need to get a version out that Sage can use. The current GMP spkg in Sage really bothers me. I don't think it matters if the Windows code allows for renaming to mpir.h though. This will be convenient for Windows users. Bill. 2008/11/1 Cactus <[EMAIL PROTECTED]>: > > > > On Nov 1, 1:11 am, mabshoff <[EMAIL PROTECTED] > dortmund.de> wrote: >> On Oct 31, 6:06 pm, "Jason Martin" <[EMAIL PROTECTED]> >> wrote: >> >> > Hi All, >> >> Hi Jason, >> >> > Well, I'm now comfortable with writing 64-bit assembly code for >> > Windows (a side effect of NIST specifying Windows Vista as the >> > benchmark platform for the hashing competition). >> >> Interesting to say the least. >> >> > So, *if* there is >> > sufficient interest, I'd be willing to look at merging the separate >> > Windows vs. *nix x86_64 code into one file. This would require >> > passing a parameter to the Yasm command lines to indicate the OS. Is >> > this a worthwhile pursuit or is there something else more pressing at >> > the moment? >> >> For me the highest priority item is the Moller's gcd code which has >> already been merged. What is the status of the code, i.e. performance, >> any known bugs, etc? >> >> > --jason >> >> Cheers, >> >> Michael >> >> > Jason Worth Martin >> > Asst. Professor of Mathematicshttp://www.math.jmu.edu/~martin > > Hi Jason > > Bill and I started down the path of having common assembler code but > it proved very difficult because the two ABI's are very different in > handling exceptions. > > Microsoft have given security requirements priority over performance > in WIndows x64 and a consequence of this is that stack use is > constrained in such a way that it can be statically analysed and also > unwound in a particular way. What this means in practice is that > stack use and register saves and restores are very strictly controlled > in a way that prevents a number of the tricks that can be used to gain > speed. The Windows assembler code is hence a few % slower than the > equivalent *nix code. > > Bill and I concluded that it would be quite difficult to merge the two > sets of code in a way that met the Windows constraints without > impacting on the speed of the *nix code. I am very willing if you > would like to try this to co-operate with you on it - but I don't > think it will be a 'walk in the park'! > > On another issue, the big outstanding possible change for me on the > WIndows side is whether we edit all the GMP files to change 'gmp.h' > includes to 'mpir.h' or leave thsese as they are. > > Right now I build the Windows version of MPIR by naming this include > as gmp.h during the build, after which I copy gmp.h into mpir.h for > use by MPIR applications. This works well enough for Windows and I > would not be inclined to change this from a pure Windows perspective. > But I would be keen to know what Bill and others think about this. > > Brian > > > > It is possible that the *nix assembler code could be recast to meet > the Windows constraints > > This means that all register saves and restores have to be done in > what are called function prologues and epilogues with saves and > restores in the function body being prohibited. during the execution > of the function body the stack pointer is fixed with the only > exception > > In WIndows x64 > > > > --~--~---------~--~----~------------~-------~--~----~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/mpir-devel?hl=en -~----------~----~----~----~------~----~------~--~---
