Integer Do's And Don'ts

[Gerald Hernandez]

Jay,

I would expect P/Invoke to be largely agnostic also

In other words I can understand platform = 32bit or 64bit or Any, I just
haven't seen the explanation on why both x64 & Itanium...

Ah, good point. That is supposed to be the beauty of .Net in the first
place! I'll keep my eyes open for some sort of better explanation. Might be
interesting. Got out of the server business shortly before the buzz of x64.
Didn't sell many Itanium servers. Customers would buy like 4-32bit Linux
boxes and got better overall throughput for a whole LOT less money.

You have the 80/20 rule mapped to a AutoText or something? ;-)
But it is spot on and worth repeating.
Haven't looked at the Beta stuff yet. Maybe I should get up to speed.

Gerald

 

[Guest]

Reply to earlier topic on this thread:
IL contains a native int type which is surfaced in managed languages as
System.IntPtr; that type has integer semantics and will be 8-bytes on a
64-bit machine and 4-bytes on a 32-bit machine (IntPtr.Size is a static
property which can be used to cheaply determine bitness programatically).

As for why there are X64 and Itanium options?
An answer (not the only one, but a good one) is P/Invoke. If you're
P/Invoke-ing out to a OS provided DLL you can be pretty sure that it will
exist on both IA64 and X64 platforms... But, if you have some native code
from somewhere else that you need to P/Invoke to and you want to ship it with
your product say; then you need to make sure to include both IA64 and X64
versions if you want your app to run on both platforms. What if the vendor
who wrote the component didn't provide both versions, or didn't bother
compiling both versions (it is worth noting that native IA64 code is
significantly harder to write than X64 code, and there isn't nearly as much
IA64 penetration in the marketplace as there will be with both AMD and Intel
X64 systems now out)?

Thus we allow you to bind your app to a single 64-bit platform. If you
compile your app with /platform:anycpu then it will run under 64-bits on a
64-bit machine which is more or less what you want. The only case I can
imagine where you might want a more generic 64-bit only marking would be for
unsafe code that is compiled to be 64-bit specific (but not platform
specifc)... In that case most of the bitness specific code is around pointer
sizes and using proper pointer types in C# will let you avoid that... I don't
even think that you can use straight pointers in VB so the point is moot.
Even so, you could concievably write your code with an if (IntPtr.Size == 4)
{ /* 32-bit code */ } else { /* 64-bit code */ }. As IntPtr.Size is a static
property which is hardcoded by the runtime to be 4 or 8 depending on the
platform a smart JIT (which I believe ours to be) should be able to inline it
and use its dead code eliminator to throw away the non-executed half of the
conditional as well as the conditional statement itself.