[Bf-committers] 64 bits migration, windows/unix

[Ted Schundler]

On the 64 bit issue, what is the preffered method for dealing with
padding? (Sorry if this was addressed somewhere already and I missed
it)
Blender3D.org's blurb on sdna structs says "structures are always
multiples of 8 bytes in size", But if you have an odd number of
pointers, in the struct, there's no guarantee of that.

For instance, the bSoundActuator here (just picked on somewhat at
random looking for padding examples):
http://astro.scu.edu/~ted/oss/blender/bf-dox/d3/dfb/DNA__actuator__types_8h-source.html#l00064
On a 32-bit architecture it is 64-bit aligned, but on 64-bit, with a
64-bit pointer, it isn't.

Should such structs have an extra pointer pad variable just in case?
Or should it have an extra 4 bytes, so on 32-bit platforms, it is at
least 32-bit aligned, and 64-bit aligned on 64-bit platforms.


Ted

On 4/30/05, Ton Roosendaal <ton at blender.org> wrote:
> Hi,
> 
> We'll have to define the Blender standard for migrating to 64 bits for
> all platforms... unfortunately the unix and windows worlds haven't
> adopted the same standard...
> 
> Check this diagram;
> http://developer.apple.com/macosx/images/lp64compare.gif
> 
> The key difference is that;
> 
> - Windows keeps the "long" 32 bits in all cases, for unix it is 32 or
> 64 bits.
> - Windows doesn't have a "long long" (int64 instead).
> 
> With Blender's unix origins - already tested for 32/64 bits in the past
> - it would be simplest to investigate if we can typedef/define the
> Windows version to follow the LP64 standard.
> If we can do that, no further #ifdef exceptions are needed to patch our
> code to be 32/64 bits compliant for all platforms.
> 
> So, I would like a Windows 64 bits developer to check on the following;
> 
> 1) Patch BLI_winstuff.h
> 
> Something like this could work: (blenloader/intern/genfile.c uses it)
> 
> #ifdef WIN32
> typedef long long __int64;
> #endif
> 
> #ifdef WIN64
> typedef long long __int64;
> typedef long __int64
> #endif
> 
> One note though... the BLI_winstuff.h is only included in the
> blender/source/ tree, not for our blender/intern/ and blender/extern/
> libraries. These each have to be checked on 32/64 issues as well.
> 
> 2) Cleanup of platform #defines
> 
> We now already use a mix of WIN32 and _WIN32 to patch OS specific code,
> this is in all cases not 32 bits related, so we need a new generic
> define.
> 
> I hope Microsoft / Cygwin has another standard already. This better not
> gets patched in the BLI_winstuff.h, since we also have an intern and
> extern libraries to take care of.
> 
> 3) Verifying DWORD referrals
> 
> In the Blender code are a couple of windows-only functions or C files.
> Check the MSDB website for the porting guides for 64 bits, with several
> notes on proper 32/64 bits code.
> 
> -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
>