[Bf-committers] AMD64 bit support issues

[Ken Hughes]

Ton Roosendaal wrote:
> Hi,
> 
>> I've got a working build right now using which uses uintptr_t and  
>> intptr_t instead of long
> 
> Hrms, this is not what I talked about. Note that Blender was 64 bits  
> compliant between 98 and 2001, succesfully using the LP64 convention.
> That way you also benefit work done already (like in file reading and  
> DNA). Only newer parts of code need to be checked.

Ok, first let me back up to your earlier e-mail:

 > It wouldn't be hard to typedef things in winstuff.h to make it
 > following that standard too.

Can you give an example?  I can't see how to do this without either
(a) changing all the casts from int or long to void *
(b) creating a new datatype which is the same size as a long, consistent 
on each platform
(c) typedef-ing long to be long long for windows, which AFAIK is not 
possible.

I personally don't mind just changing everything to use a long, since it 
will work for me, but it doesn't help 64-bit Windows developers.  On the 
other hand maybe I'm just really dense; is this is non-issue on Win64? 
Is a long really 64-bits there?

>>  and I'm trying to decided the best way to get this into the 
>> necessary  files and include search paths.  Currently I've changed 
>> about 8  makefiles and 6 SConscript files
> 
> I'd appreciate if you would first mail the list what you exactly want  
> to do?

Trust me, I'll be thrilled to get everyone else's blessing before I make 
any permanent changes :-)  I'd like to make as few as possible.

>> but I'm planning today to examine the various search paths more  
>> closely to see what the current settings are.  It looks like the most  
>> painless way right now would be add or modify include files in 
>> blender  and the game engine; I don't see any common include path 
>> which both  use consistently.
> 
> No idea what you try... the 64 bits versions we did in past didn't need  
> much tweaks in .h or makefiles...

Again, I believe you, but do the Windows developers care?

>> So what's the preferred approach?  Duplicate header files with no  
>> change to the builds, or one header file and changes to the builds  
>> (which will
>> involve the other platform maintainers)?
>>
>> (Actually, if someone (ton?) can give me a definitive direction to  
>> take, this could still make it before the cvs freeze)

> This is definitely for after 2.40 is out!

No problem; but in the meantime I'd like to be able to work on this, and 
would appreciate some direction.  I discovered today that two old .blend 
files which work fine on my 32-bit machine give memory corruption 
warnings and segfaults on my 64-bit machine.  So I'm motivated to work 
on the 64-bit port; otherwise I may as well install a 32-bit version of 
the OS.

Ken


> -Ton-
>