[Bf-committers] AMD64 bit support issues

[Ken Hughes]

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?

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
>