On Aug 14, 12:03 pm, jason <ja...@njkfrudils.plus.com> wrote:
> 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 -- Hide quoted text -
>
> - Show quoted text -
I agree but this is just one of many examples of GMPs lack of
consistency and haphazard overall structure..
And even considering _LONG_LONG_LIMB alone, you can choose between:
#if _LONG_LONG_LIMB
#ifdef _LONG_LONG_LIMB
#if defined _LONG_LONG_LIMB
and other variations in its extensive use throughout the code.
We can go through and remove these by using definitions based on
GMP_LIMB_BITS - I'll help if you want to do this.
Brian
--
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.
