64-bit .NET questions, for anyone in the know...

[JDeats]

1. Will there be different 64-bit .NET implementations for Intel and AMD
64-bit processors or will they share a common 64-bit CLR?

2. Will .NET managed code compiled for the 32-bit CLR be binary compatible
with the 64-bit CLR or will a recompile with code changes be required?

3. Will 64-bit CLR processes be able to address process space above the
2-Gig memory limit imposed by the 32-bit architecture?

4. Will there be a significant performance gain in the 64-bit managed code
over a 32-bit counterpart?

5. How can I apply for the 64-bit .NET Framework beta program?

 

[Daniel Weber]

1. Will there be different 64-bit .NET implementations for Intel and AMD

64-bit processors or will they share a common 64-bit CLR?

Can you give me a hint where you found information about a 64-bit CLR ?
From what I understand, it's just a thin layer on the operating system. So,
it would
really surprise me if there would be a 64-bit CLR, even because it was
designed to be
independent from processors.

daniel

 

[Daniel O'Connell]

Can you give me a hint where you found information about a 64-bit CLR ?
From what I understand, it's just a thin layer on the operating system. So,
it would
really surprise me if there would be a 64-bit CLR, even because it was
designed to be
independent from processors.

Well, each processor requires a JIT compiler that can emit code for that
processor(probably a major change). A garbage collector and memory
allocation system that can handle allocations and cleanups in the proper
method for that processor and memory architecture(potentially not much of a
change, but I don't know for sure). Some types will change(such as IntPtr),
etc.
In short, each processor type would, for sake of optimization and
compatibility, need its own set of those particular components(plus more
than likely several others that aren't written in managed code, I'm not
sure).
The AA 64 level processors are not binary compatible with the IA64 ones.
They use entirely different instruction sets and are entirely different
architectures. Each has a method to run IA32 code, with the AMD being a
usable method and IA64 being a thunk just to make it work. So it is pretty
much impossible, short of an additional level of emulation, for an
implementation of an IA64 JIT to run on an AA64 processor, and vice versa.

However, I think the JIT design of the framework could lend itself very well
to IA64's design, I am curious how many optimizations the JIT team is able
to put into that JIT compiler as far as predication and the like goes.

 

[JamesMason]

The following answers to your questions are from Microsoft via MSDN TV
and other misc articles:

1. Will there be different 64-bit .NET implementations for Intel and AMD
64-bit processors or will they share a common 64-bit CLR?

Yes, the 64-bit CLR will support/be optimized for both AMD and Intel's
64-bit architectures.

2. Will .NET managed code compiled for the 32-bit CLR be binary compatible
with the 64-bit CLR or will a recompile with code changes be required?

In most cases all managed code will be binary compatible and therefor
not require a recompile (e.g. just copy over your existing 32-bit
compiled .NET EXE Assembly and DLLs and the 64-bit CLR will attempt to
run it). There are a few exceptions. Some of the primitive types take
up different memory sizes (float's if I recall) so if you're
performing a logical check and taking action based on the memory size
of a float you will have to rewrite that part of your code, there are
a few other small issues such as this.

Unmanaged code (including COM references and Win32 API dll references)
will not run in the 64-bit CLR. When the next VS ships the Framework
will offer something called WoW32 (Windows-On-Windows) that will allow
you to go in to the global assembly cache and tag a given assembly to
run under WoW32 or CLR64. If it's taged for Wow32 then it will run as
32-bit code and unmanaged references will work fine in this mode. The
trade off is that you loose all the 64-bit advantage. Unfortunately
there are no plans for a mixed mode (where the managed code can run in
64-bit and the unmanged in 32-bit. the process has to be one or the
other.

3. Will 64-bit CLR processes be able to address process space above the
2-Gig memory limit imposed by the 32-bit architecture?

Yes, this is one of the key advantages.

4. Will there be a significant performance gain in the 64-bit managed code
over a 32-bit counterpart?

You will get immediate performance increase thanks to the
optimizations of the 64-bit CLR, the benchmarks aren't in yet to tell
us how much improvement to expect. The beta isn't useful for that so
we'll have to wait.

5. How can I apply for the 64-bit .NET Framework beta program?

I believe it's closed now. The 64-bit .NET Framework should be
available first or second quater 2004 as part of the Whidbey (Visual
Studio.NET 2004) release.

 

[Jon Skeet]

In most cases all managed code will be binary compatible and therefor
not require a recompile (e.g. just copy over your existing 32-bit
compiled .NET EXE Assembly and DLLs and the 64-bit CLR will attempt to
run it). There are a few exceptions. Some of the primitive types take
up different memory sizes (float's if I recall) so if you're
performing a logical check and taking action based on the memory size
of a float you will have to rewrite that part of your code, there are
a few other small issues such as this.

I seriously hope that's not true. The System.Single and System.Double
types have very specific sizes. There are certain circumstances where
larger sizes can be used for intermediate calculations etc, but the
sizes of the types themselves are well-defined. It would be ludicrous
to get back to the situation of C where types mean different things on
different compilers etc.

Of course, the CLR may wish to lay things out in memory differently,
when it's allowed to - if that's what you mean, it makes perfect sense.
(Things may be better aligned on 64 bit boundaries than 32 bit
boundaries, for instance.)

 

[JamesMason]

For most cases the Framework will resolve the problem, for eample, you
define an integer as:

int myval = 0;

The runtime should now to use Int64 instead of Int32, it's more
efficient to use the full register. If you explicitly define your
primitives, such as:

System.Int32 myval = 0;

Then the compiler will force a half-register and the overall
performance will be hindered (not sure if this will be enough to make
a difference). I wish I know more about this, if anyone does please
feel free to correct me or append to this information.

 

[Jon Skeet]

For most cases the Framework will resolve the problem, for eample, you
define an integer as:

int myval = 0;

The runtime should now to use Int64 instead of Int32, it's more
efficient to use the full register.

No! It should still use Int32, because that's what the C# spec calls
for. Now, if it wants to emulate that by using a 64 bit register and
being cunning, that's one thing - but gratuitously violating the C#
specification is something different entirely.

If you explicitly define your
primitives, such as:

System.Int32 myval = 0;

Then the compiler will force a half-register and the overall
performance will be hindered (not sure if this will be enough to make
a difference).

The C# compiler will produce IL code using System.Int32 whether you do

int myval=0;
or
System.Int32 myval=0;

- the IL will be identical.

 

[Eric Gunnerson [MS]]

For most cases the Framework will resolve the problem, for eample, you
define an integer as:

int myval = 0;

The runtime should now to use Int64 instead of Int32, it's more
efficient to use the full register. If you explicitly define your
primitives, such as:

System.Int32 myval = 0;

Then the compiler will force a half-register and the overall
performance will be hindered (not sure if this will be enough to make
a difference). I wish I know more about this, if anyone does please
feel free to correct me or append to this information.

As Jon points out, the C# standard (and the CLR standard as well) give
specific sizes for the types. The 64-bit CLR will not change these sizes.

IIRC, the only type that will change in size between the two is IntPtr

--
Eric Gunnerson

Visit the C# product team at http://www.csharp.net
Eric's blog is at http://blogs.gotdotnet.com/ericgu/

This posting is provided "AS IS" with no warranties, and confers no rights.

 

[Daniel O'Connell]

As Jon points out, the C# standard (and the CLR standard as well) give
specific sizes for the types. The 64-bit CLR will not change these sizes.

IIRC, the only type that will change in size between the two is IntPtr

Will the size of a reference change in the 64-bit CLR? I guess that would
depend on if a reference is a direct pointer or a lookup value, which I
don't think I know right off hand.

More importantly,in unsafe code, I would assume int *x; would be bigger than
int y; on the stack as well, which is something to consider as far as what
kind of an issue could that be in interop structures? Will the marshaller be
capable of properly handling calls into 32 bit code via WoW64 as far as
pointers are concerned?