[CLN-list] MinGW64 build

[Robert Szalai]

Hi Alexei,

in the end I managed to make a patch that works and a rather clean one in my view. What I did was the following
- changed long to intptr_t and unsigned long to uintptr_t in all the hash code related files.
- change the char* bit size comparison with long to intptr_t in both
 autoconf/intparams.c and m4/intparams.m4
- in types.h redefined 32 and 64 types in terms of (u)intptr_t if they match
this is necessary when overloading functions so that there will be no duplicate overloads
- In object.h cl_I is now defined cl_int and cl_uint are now defined by intptr_t and uintptr_t
 therefore overloaded functions are ifdefed out when the argument bitsize is the same as the pointer size to avoid clash.
- changed the printing routines in io.h and their implementations to accept intptr_t and uintptr_t
- in cl_macros.h the long and long long constants are casted into (u)intptr_t
- since operator[] is overloaded many times except with std::size, so I needed to cast some vector indices to unsigned long from size_t. This was the largest index possible anyway. On win64 it will limit to 32 bits unfortunately.
Someone might want to rethink how operator[] is overloaded.
- there are three WIN64 ifdefs
1. word alignment is only 4 
2. integer/conv/cl_I_from_UL.cc and integer/conv/cl_I_from_L.cc has to be compiled for WIN64 otherwise this conversion is missing during linking.

The patch is tested with 'make check' on 3 OSes times 2 bit sizes
32/64 bit OS X Lion
32/64 Linux on Fedora 17
32/64 Windows through wine with the MINGW32/64 cross compilers

the patch is unfortunately monolithic, I cannot break it up otherwise it does not compile. It is after all only changing long into intptr_t and dealing with the dependencies. It should not affect performance, it should leave things invariant for anything other than WIN64, since the assumption was that long == intptr_t.

With best wishes,
Robert
-------------- next part --------------
A non-text attachment was scrubbed...
Name: subs8.patch.gz
Type: application/x-gzip
Size: 9555 bytes
Desc: not available
URL: <http://www.cebix.net/pipermail/cln-list/attachments/20120814/d23bbe73/attachment.gz>
-------------- next part --------------

On 13 Aug 2012, at 08:29, Alexei Sheplyakov wrote:

> Hello,
> 
> On Fri, Aug 10, 2012 at 03:43:46PM +0100, Robert Szalai wrote:
> 
>> What do you think I need to do to port CLN to LLP64 model.
> 
> long within CLN has (at least) 3 meanings:
> 
> 1. An integer as large as a pointer.
> 2. On a 64-bit platform: a 64-bit integer.
> 3. Just long (say, in conversion functions).
> 
> One need to classify every occurrence and replace 1) with (u)intptr_t,
> 2) with int64_t, and leave 3) as is.
> 
>> Also if I manage to carry this out, would you be interested in merging it?
> 
> That depends. A mega-patch without any explanation at all (like the one
> you've already sent) would be certainly rejected (sorry, we want CLN to
> be a bit maintainable). 
> 
> The suggestions below can greatly increase the chances of your changes
> being accepted:
> 
> 1. Split your changes into separate self-contained patches. For instance,
>   if the changes include both bug fix and performance enhancement(s),
>   separate those changes into two (or even more) patches. On the other hand,
>   if you make a single change to numerous files (like API update), group
>   those changes into a single patch.
> 2. Describe your changes: explain what problem you are trying to solve, what
>   are you doing to solve it, and why you are taking a particular approach.
> 3. Mind the performance, please.
> 4. Don't introduce regressions (in particular, build failures are not
>   appreciated at all).
> 5. Don't add (even more) compiler- and OS-specific code unless it's
>   absolutely necessary.
> 6. Don't mix platform specific platform specific code with generic one (put
>   the platform specific code into a different function, macros, file, etc).
> 
> @ developers: should we add `How to submit patch' entry to the FAQ?
> 
>>> It's a type tag. Its purpose is to distinguish between the immediate
>>> values (small integers, short floats) and the actual pointers. See
>>> include/cln/object.h for more details.
>> 
>> Quite interesting way of saving space.
> 
> The point is that small objects (integers) are allocated on the stack which
> is *much* faster than allocating them in the heap. So actually it's a way
> to improve the performance.
> 
> 
> Best regards,
> 	Alexei
> 
> _______________________________________________
> CLN-list mailing list
> CLN-list at ginac.de
> https://www.cebix.net/mailman/listinfo/cln-list