Declares, pointers, & 32/64-bit confusion

General
1

I’ve got some declares where I’m doing this kind of thing…

addressMB is a 4-byte MemoryBlock created for the sole purpose of holding the address of AnotherMemoryBlock.

addressMB.Ptr(0) = AnotherMemoryBlock

When I want to fiddle with bytes in the middle of AnotherMemoryBlock, I calculate the location for fiddling by adding an offset to the address stored in addressMB, like so,

location = addressMB.Long(0) + offset

and I pass that location as an Integer to some declares that are expecting a pointer to a C string or other memory structure.

All of which works fine. But I’m wondering about the 4-byte/Long(0) part and whether this should work fine.

I dusted this code off from several years ago, when my computer only had 2 GB of RAM, but now that I’m on a 64-bit Mac with 32 GB of RAM I’m wondering how the Long(0) which returns a 4-byte value from a 4-byte addressMB manages to work as a pointer to a memory address that could easily be larger than 4 bytes can hold.

Maybe it’s not working fine, at least some of the time. Maybe it only appears to be working fine, and my computer’s about to crash at any moment.

Do I need to change the way I’m doing these declares, and/or change the way I’m storing and accessing pointers to use, say, an 8-byte MemoryBlock and Int64Value(0) instead of Long(0)? And, if so, do I need to do some #If Target64Bit switching to do different things on, e.g., 32-bit Linux vs 64-bit OS X?

Can anyone enlighten me?

Signed,
Confused, ignorant, and worried in Florida

2

in 64bit, you will have to use Int64 for pointer values instead of Int32.

3

Thanks. I suspected that must be the case. Does that mean I need to do the #If Target64Bit switch for running on 64-bit OS X vs 32-bit Linux, or can I just use Int64 and Xojo will convert that to a 32-bit Integer if running on 32-bit platform?

I guess that’s a more general question. What happens if you’re using MemoryBlock.Int64Value(n), or just using Int64 and UInt64 variables, and you run your app on a 32-bit Linux box? I’ve never even thought about it before.

4

often bits are cut. But problem will be if we ever get back to big endian. Than you can’t simply store 32bit pointer and read as 64bit integer.

5

Not currently it can’t - we only build 32 bit apps and the OS takes care of making your process think it all fits inside 0 - 4Gb (or so)

6

Thanks, Norman. Does that mean I can (currently) just use Int32s/Longs for pointers and not worry about it, and behind the scenes the OS will translate that to its 64-bit address space when my code is running on a 64-bit platform?

Also, I just realized that #If Target64Bit doesn’t do anything, i.e., it’s always false. Xojo reports it’s running on a 32-bit system even when it’s not. I never noticed before, because I never thought about it before. It’d be great if I didn’t have to think about it, if Xojo and the OS just handle it and let me play in a pretend 32-bit world, and I think that’s what happening. Is it?

7

[quote=93063:@Walter Purvis]Thanks, Norman. Does that mean I can (currently) just use Int32s/Longs for pointers and not worry about it, and behind the scenes the OS will translate that to its 64-bit address space when my code is running on a 64-bit platform?
[/quote]
Your process is actually 32 bit - the OS handles everything to make your entire process operate as a 32 bit process on a 64 bit OS
You don’t have to worry about that portion of it
Currently a Ptr and an integer are both 32 bits.

Correct … this is not “am I running on a 64 bit system” its “am I compiling a 64 bit executable”
http://documentation.xojo.com/index.php/Target64Bit
Its like the TargetLinux, TargetWin32 & TargetMacOS targets
IF you’re compiling for Win32 then that code in the #if will be included
Same for #if Target64bit - since you cannot compile a 64 bit executable the code in there is NEVER included
It’s NOT a runtime check

No it correctly reports it IS a 32 bit exe being compiled if you mean something like

#if Target64bit msgbox "64 bit" #else msgbox "32 bit" #endif
Since you cannot compile a 64 bit exe today its not surprising that this would always say “32 bit”

Pretty much
When we get to being able to compile 64 bit THEN you may have to worry about the differences between things although I expect that Ptr and Integer will always be the same size (32 bits in a 32 bit executable & 64 bits in a 64 bit executable)

9

Awesome, Norman. Thanks for the detailed explanation.