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 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@ginac.de https://www.cebix.net/mailman/listinfo/cln-list