[Bf-committers] AMD64 bit support issues

[Ton Roosendaal]

Hi Ken,

Check this diagram;
http://developer.apple.com/macosx/images/lp64compare.gif

And my post on this list;
http://projects.blender.org/pipermail/bf-committers/2005-April/ 
010664.html
(and read the follow ups)

For Blender we've adopted (6 years ago already) the LP64 standard. It  
wouldn't be hard to typedef things in winstuff.h to make it following  
that standard too.

Maybe you like to collect all info in a wiki page, for a 64 bits  
migration guide? :)

> One of the links someone sent earlier points out that a long is  
> 32-bits under Windows, even on 64-bit systems:
>    http://blogs.msdn.com/volkerw/archive/2005/07/06/436074.aspx
> Everything I've read so far recommends using intptr_t or uintptr_t.
>
> As for converting addresses to and from 32-bit ints, I'm assuming this  
> is only for addresses based on allocation from Blender's memory  
> routines?

Each use of a malloc will give aligned memory (in 64 bits systems). So  
the conversion can safely strip off the three least significant bits.
Note that this won't work (of course) for pointers pointing to the  
stack. But these don't need to be stored or converted.

Here's a piece of untested code for how the conversion could go.

What needs a test is if the copying from a 64 bits long (signed) maps  
OK to a signed int, especially when truncating bits.
To bypass errors, I just copy it from/to an unsigned int first, then  
read that with a cast to a signed integer.

void *pointer_from_int(int ipointer)
{
	unsigned int *upointer;

	/* note; I am not sure about this upointer trick.... will signed to
		unsigned copying work on all OS's? */

	upointer= (unsigned int *)&ipointer;

	if(sizeof(void *)==4) {
		return (void *)*upointer;
	}
	else {
		static int firsttime= 1;
		static long address_space= 0;

		if(firsttime) {
			void *poin= malloc(8);
			long poinval= (long)poin;

			address_space= poinval & ~7FFFFFFFF;  /* allows 32 Gig space */
			firsttime= 0;
			free(poin);
		}
		
		return (void *)( ( ((long)*upointer) << 3) | address_space );
	}
}

int int_from_pointer(void *pointer)
{

	if(sizeof(void *)==4) {
		return *( (int *)pointer);
	}
	else {
		long poinval= ((long)pointer)>>3;
		unsigned int uval= (unsigned int)poinval;

		return *( (int *)&uval );
	}
}

-Ton-

>
> Ken
>
> Ton Roosendaal wrote:
>> Hi,
>> Where possible, pointers should cast to long. If we (happens in some   
>> places) temporally store pointers in ints (Blender structs), theres a  
>>  bigger issue:
>> - either recode that to do it different
>> - or change the struct to use long (not much advised..., since this   
>> temporal storage is typically hack)
>> - or devise a #define or function call that reliably converts the 64   
>> bits address space back to an int, and vice versa (shifting addresses  
>>  three bits will give a 32 Gig address space).
>> That latter solution I like, but then we need a solution for  
>> recovering  the lost address space bits... this is OS/platform  
>> dependent, so could  be solved in a separate c file with a load of  
>> #defines...
>>
>> -Ton-
>> On 27 Oct, 2005, at 23:43, Ken Hughes wrote:
>>> I've just built an AMD64 linux system with intention of making it my  
>>>  secondary development machine and helping with the port to 64-bits.  
>>>  (Maybe in the future I'll install WinXP64, Solaris, FreeBSD, and   
>>> anything else I can get my hands on).  I compiled without the game   
>>> engine using scons and only had one error due to pointer size  
>>> issues.  Have just started trying to compile with the game engine.   
>>> Reading  back through the bug and patch trackers there are some  
>>> posts about  AMD64 patches (#2702 is game engine, #3264 seems  
>>> general but doesn't  include any patch!) but wondered where I should  
>>> go next.
>>>
>>> I've run gcc with more warning switches enabled and started  
>>> collecting  pointer issues from there; should I examine and correct  
>>> where  necessary?  For that matter, what is the "correct" way to fix  
>>> pointer  <-> number casts?  Doesn't seem like just changing to a  
>>> long is  correct either.
>>>
>>> Is there anyone else tackling this problem as well?  Want to share   
>>> information?
>>>
>>> Ken
>>> _______________________________________________
>>> Bf-committers mailing list
>>> Bf-committers at projects.blender.org
>>> http://projects.blender.org/mailman/listinfo/bf-committers
>>>
>>>
>> ---------------------------------------------------------------------- 
>> -- --
>> Ton Roosendaal  Blender Foundation ton at blender.org   
>> http://www.blender.org
>> _______________________________________________
>> Bf-committers mailing list
>> Bf-committers at projects.blender.org
>> http://projects.blender.org/mailman/listinfo/bf-committers
>
> _______________________________________________
> Bf-committers mailing list
> Bf-committers at projects.blender.org
> http://projects.blender.org/mailman/listinfo/bf-committers
>
>
------------------------------------------------------------------------ 
--
Ton Roosendaal  Blender Foundation ton at blender.org  
http://www.blender.org