----- Original Message -----
From: "Cactus" <rieman...@gmail.com>
To: "mpir-devel" <mpir-devel@googlegroups.com>
Sent: Saturday, August 14, 2010 1:55 PM
Subject: [mpir-devel] Re: MPIR 2.2
On Aug 14, 12:36 pm, "jason" <ja...@njkfrudils.plus.com> wrote:
trunk now builds under mingw64 (C only) (ie
./configure --build=none-pc-mingw32)
It passes make check (except for t-locale , which fails on MSVC as well)
I've tested vs2008 , and all is OK , I can't imagine any problems with
vs2010
I'll change the t-locale test so that it is skipped for WIN64
There are some cosmetic changes that need to be done.
config.guess reports x86_64-pc-mingw32 , ie it doesn't detect the cpu ,
the
pc bit should be w64 and mingw32 should be mingw64 , and upgrade to GNU
config may fix some of these.
make speed,tune fails
I've only tried a static lib so far , not tried make try , etc......
Jason
----- Original Message -----
From: "jason" <ja...@njkfrudils.plus.com>
To: "mpir-devel" <mpir-devel@googlegroups.com>
Sent: Saturday, August 14, 2010 12:03 PM
Subject: [mpir-devel] Re: MPIR 2.2
The whole business of defining LONG_LONG_LIMB is a bad idea. What I
mean is that good programming is to hide infomation , once we define
mp_limb_t (as whatever) in mpir.h , then the rest of mpir's code , and
any programs built on libmpir should not need to know that it is a
long or long long or whatever. If they want the size , use
GMP_LIMB_BITS.
There are only two places where this may be a problem.
Constants can need LL instead of L , but proper use of CNST_LIMB(x)
macro covers this
printf("%ld",(mp_limb_t)x); need to use the proper gmp_printf
We can still define LONG_LONG_LIMB (after the fact) for all those
badly writen librarys out there that depend on it , but I think
internally we should not depend on it.
I think the only place a long long limb is used in anger , is Win64 ,
or the only modern ABI.
Anyway , to get mingw64 working , I will stick to how we do it for the
moment.
Jason
On Aug 14, 11:02 am, Jason <ja...@njkfrudils.plus.com> wrote:
> On Saturday 14 August 2010 10:03:09 Cactus wrote:
> > On Aug 14, 9:00 am, Cactus <rieman...@gmail.com> wrote:
> > > On Aug 14, 4:02 am, "jason" <ja...@njkfrudils.plus.com> wrote:
> > > > Hi Brian
> > > > I notice that for win64 you have a scipt gen_mpir_h.bat which
> > > > define's
> > > > LONG_LONG_LIMB 1
> > > > Is there any reason you did it this way , rather than at somewhere
> > > > before line194 in gmp-h.in
> > > > #ifdef _WIN64
> > > > #define _LONG_LONG_LIMB 1
> > > > #endif
> > > > because for the mingw64 I need to set it anyway.
> > > There are several reasons for this, one being a desire to be able to
> > > define what I need on Windows without changing files in the MPIR
> > > distribution. This is partly historical and comes from my GMP build
> > > at a time when I could not expect TG to allow any Windows changes
> > > into
> > > gmp_h.in.
> > > The second, more important, reason is that this aligns with the
> > > intended pre-processing of gmp-h.in, which includes @symbol@ values
> > > that are intended for substitution when gmp-h.in is used to build to
> > > build gmp.h or mpir.h. I have to either remove or substitute all
> > > these @symbol@ values so it is natural to do the definitions during
> > > this process (whiich I assume parallels what happens in the
> > > Unix/Linux
> > > builds).
> pretty much
> > > But it turns out that the are significant benefits for the Visual
> > > Studio IDE, that can be much faster when such conditionals are not
> > > present because its intellisense database, which enables code and
> > > symbol browsing in the IDE, background compiles both code paths for
> > > conditionals in order to create its database (this is not quite what
> > > it does but it would be hard to explain the full story of how it
> > > avoids the combinatorial explosion in code paths).
> > > But if you need it in gmp-h.in, I think my script will still work
> > > provided all the associated @symbol@ elements in gmp-h.in are
> > > removed.
> > > Brian
> There is another place it is used.
> When running configure (This is before we know how to fill all these
> @symbols@)
> , the configure script compiles a short c prog to test the size of a
> mp_limb_t
> ie output from configure (linux 64bit)
> checking for assembler byte directive... .byte
> checking how to define a 32-bit word... .long
> checking if .align assembly directive is logarithmic... no
> checking if the .align directive accepts an 0x90 fill in .text... yes
> checking size of unsigned short... 2
> checking size of unsigned... 4
> checking size of unsigned long... 8
> checking size of mp_limb_t... 8 #######################
> creating config.m4
> configure: creating ./config.status
> config.status: creating Makefile
> config.status: creating mpf/Makefile
> I not sure it is strictly necessary , but for the mo we need it . As I
> rip
> autotools to bits , it may not survive.
> Todo this is sets the define __GMP_WITHIN_CONFIGURE and just includes
> gmp-h.in
> So I can guard it with the above define , which is not set by MSVC .
> Although I
> may need to set it again for the build , I'll have to try it to find
> out.
> > In fact, provided your definition occurs before line 60 (I think), all
> > my script will do is to add a redundant define since it is guarded.
> > If you wish to add it later, all it needs is a guard to avoid multiple
> > definitions.
> > But I assume that the Unix/Linux builds have to process gmp-h.in to
> > produce mpir.h including the relevant substitutions --- shouldn't the
> > mingw64 build do the same?
> > Brian- Hide quoted text -
> - Show quoted text -- Hide quoted text -
> - Show quoted text -
--
You received this message because you are subscribed to the Google Groups
"mpir-devel" group.
To post to this group, send email to mpir-de...@googlegroups.com.
To unsubscribe from this group, send email to
mpir-devel+unsubscr...@googlegroups.com.
For more options, visit this group
athttp://groups.google.com/group/mpir-devel?hl=en.
The auxiliary programs (speed, try and tune) all build on Windows x64
so something must be different on mingw64.
Now onto the Windows assembler with mingw64!
As far as I can tell mingw64 will work with the stack unwinding
stuff. Unfortunately YASM dwarf2 debug output fails with GDB so I am
not sure about this as I have not been able to trace any assembler
code.
But my AES code uses prologues and epilogues and it works fine with
mingw64.
Brian
Please discuss any necessary changes to the files in mpn\x86w and mpn
\x86\-64w
--
Yeah , we need to change all the *.asm files in x86_64w to *.as , to match
unix where *.asm goto m4/gas and *.as goto yasm , is this a problem?
We need to change the include path for yasm_mac.inc in all the *.asm files
in x86_64w to something I will workout in a minute , is this a problem
Then we will get a compile , will it work ???????
I've also changed the cpuid asm code in the config.guess script to work with
both ABI's as you can not have two separate ones as (unlike 64 verses 32
bit) you cannot guaratee one will fail always
Thanks
Jason
You received this message because you are subscribed to the Google Groups
"mpir-devel" group.
To post to this group, send email to mpir-de...@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.
--
You received this message because you are subscribed to the Google Groups
"mpir-devel" group.
To post to this group, send email to mpir-de...@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.
