GMP, MPFR and VS version compatibility

[Brian Gladman]

----- Original Message ----- 
From: "Michael Abshoff" <Michael.Abshoff at fsmath.mathematik.uni-dortmund.de>
To: <gmp-discuss at swox.com>
Cc: "Jim White" <mathimagics at yahoo.co.uk>; <brg at gladman.plus.com>
Sent: Friday, July 13, 2007 9:51 AM
Subject: Re: GMP, MPFR and VS version compatibility


> brg at gladman.plus.com wrote:
>
> Hello folks,
>
>> Hi Jim,
>>
>> Please don't worry on my behalf since I am used to people here 'dissing'
>> pretty well anything to do with Microsoft irrespective of whether the
>> criticism is deserved.  In this case I don't believe it is.
>>
>> Michael's problem is not one of having to re-tool as a result of MSVS
>> changes since MS has always provided good mechanisms for moving projects
>> from older to newer VC++ versions.  In consequence anyone who builds GMP
>> with an MSVC tool chain is very unlikely to have any maintenance problems
>> (I have never had any such problems in 10+ years).
>>
>
> That is true, but downgrading your project from one version to a previous
> one is a feature that is needed. I suspect that omitting that feature
> "motivates" upgrades, just like changes in the format Word uses
> "motivates" people/companies to upgrade.

Hi Michael,

Yes, this is one possible reason.  Another is that features in the newer 
version cannot be mapped backwards and may not simply lie dormant if this is 
done.

I also feel that Microsoft should make some effort to suppport moving 
backwards but it is wrong to suggest that the inability to go in this 
direction will cause maintenance problems.

>> The problem in Michael's case is that he wants to move _backwards_ from a
>> later to an earlier version. And it's no more an MSVC issue than it is a
>> GNU/GCC/UNIX/LINUX one that moving in this direction is likely to be
>> problematic.
>>
> No, I disagree on that one. With Linux/Unix and gcc/make it doesn't make a
> difference (within reason, my might have problems on that 10 year old
> installation). but if you feel to compile GMP with gcc 2.95 it will work
> (for 32 bit at least).

That is exactly my point.  Saying you can move backwards if you ignore all 
the new features (e.g. x64 support) equally makes the MSVC backwards move 
possible (I posted details of how to do this earlier).  But moving backwards 
raises different issues to those of moving forward (i.e. maintenance) so I 
don't accept Jim's point that difficulties in doing this are indicative of 
maintenance problems.

>> In my view the major maintenance issues in providing GMP in both
>> environments are those of coping with the changes needed to exploit new
>> processors and new processor features. The specific GCC/MSVC maintenance
>> issues are the different x64 ABI, the different assembler code tool 
>> chains
>> (M4/GAS vs YASM) and the different assembler syntax (although both gas 
>> and
>> YASM are now bilingual).
>>
> And as a host to a mirror for Brian's binary gmp builds I can tell you
> that there is demand: There are literally hundreds of downloads from my
> mirror each month.
>
> Brian, do you have figures on how many lines of code you change and how
> many file you add that are not part of the build system? That way one
> could estimate if a autotools+MinGW using cl.exe+yasm port would be
> worthwhile/possible. I just remembered that ATLAS used to do the same
> thing (with the 3.6 release, the 3.7 has a new build system and will have
> support for that compiler again in the future).

The GMP team do a pretty good job with the C code and little if anything has 
to change here.  There are minor modifications to the gmp.h header file and 
to config.h to take account of some function name changes. But by far the 
largest bit of work is the addition of assembler support for new 
architectures/features in YASM format.  In my view it would be possible to 
write a Windows makefile that did all of this and allowed the compiler and 
assembler to be chosen at will.

> Currently the GMP port to MSVC is entirely dependent on you, so having an
> alternative in case you no longer are interested in doing the work (and I
> am not implying that you will stop, this is just kind of a worst case
> scenario, i.e. you get hit by a comet) is a good thing.

I agree that this is a potential problem as there will come a time when I 
drop this.  It is also worth noting that since both the Intel compiler and 
YASM exist in both environments, it is perfectly possible to contemplate a 
native build from a common makefile in either of these environments.

   best regards,

     Brian