[Bf-committers] AMD64 bit support issues
khughes at pacific.edu
Sun Nov 6 02:57:42 CET 2005
One of the links someone sent earlier points out that a long is 32-bits
under Windows, even on 64-bit systems:
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?
Ton Roosendaal wrote:
> 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...
> 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
>> Bf-committers mailing list
>> Bf-committers at projects.blender.org
> ------------------------------------------------------------------------ --
> Ton Roosendaal Blender Foundation ton at blender.org http://www.blender.org
> Bf-committers mailing list
> Bf-committers at projects.blender.org
More information about the Bf-committers