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 [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
-~----------~----~----~----~------~----~------~--~---
