[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