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 at
http://groups.google.com/group/mpir-devel?hl=en.
