[Bf-committers] 64 bits CPU support

Stefan Gartner stefang at aon.at
Wed Nov 17 19:46:29 CET 2004


Hi,
the attached patch should deal with most of the int <-> pointer stuff.
As I'm not sure whether all those changes are really necessary (especially the 
changes to intern/guardedalloc and the DNA headers), it would be nice if 
someone more familiar with blender code and 64 bit platforms than me could 
look over it. If there are no objections, I will commit my changes after the 
release dust has settled.

The patch also contains some minor changes to the Makefiles, to support 
building on Linux/x86_64.

Stuff that still needs to be done:
- update scons (not sure if there's anything that needs to be changed)
- check the 32 bit <-> 64 bit conversions in readfile.c
- make sure it works on other platforms. So far I have tested it on Linux
  (i386 and x86_64)

greetings,
sgefant

On Tuesday, 9. November 2004 12:34, Ton Roosendaal wrote:
> Hi,
>
> Here's some essential info for those interested in testing 64 bits
> binaries;
>
> Back in the nineties I ported & maintained a 64 bits Linux dec alpha
> version. We dropped this in 2001 or so... but the foundation for proper
> 64 bits support in Blender is still there. It is likely though that new
> code was added that's not 64 bits compatible (yes, not allowed to put a
> pointer in an integer), that's all to clean up.
>
> Apple is going to 64 bits in their next upgrade, will definitely check
> that out. For those interested to already work on it, there's one
> important coding rule to apply in blender:
>
> -> the variable type "long" has been typedeffed to be either 32 or 64
> bits integer, depending pointer size.
>
> So, if you want to do pointer arithmetic, or cast pointers to int, use
> a "long". Also use "long" in (DNA) structures, that gets mapped OK. And
> make sure longs and pointers are properly aligned (8 byte aligned) in
> structs that get saved in blender files.
>
> This rule might have been gone lost in recent code... or not fully
> covered in makefiles or Scons. All work todo.
>
> Oh, and hackish part in Blender needs to be checked; to map pointer
> values from 64 bits systems back to 32 bits ones (file load,
> readfile.c) there's a conversion that might need to be updated... right
> now it does: pointer_32 = (pointer_64>>3);
> This assuming that address space on a 64 bits system doesn't start
> somewhere in the billions.
>
> -Ton-
>
> ------------------------------------------------------------------------
> --
> 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: x86_64.diff.gz
Type: application/x-gzip
Size: 6633 bytes
Desc: not available
Url : http://projects.blender.org/pipermail/bf-committers/attachments/20041117/dbf911d5/x86_64.diff.bin


More information about the Bf-committers mailing list