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

"JDeats" <je****@pdq.net > schrieb im Newsbeitrag
news:b0******** *************** ***@posting.goo gle.com... 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 O'Connell]

"Daniel Weber" <dc************ *****@gmx.de> wrote in message
news:bk******** *****@news.t-online.com...

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.

Well, each processor requires a JIT compiler that can emit code for that
processor(proba bly 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(po tentially 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.
daniel

"JDeats" <je****@pdq.net > schrieb im Newsbeitrag
news:b0******** *************** ***@posting.goo gle.com...

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 O'Connell]

"Daniel Weber" <dc************ *****@gmx.de> wrote in message
news:bk******** *****@news.t-online.com...

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.

Well, each processor requires a JIT compiler that can emit code for that
processor(proba bly 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(po tentially 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.
daniel

"JDeats" <je****@pdq.net > schrieb im Newsbeitrag
news:b0******** *************** ***@posting.goo gle.com...

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?

[JamesMason]

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

je****@pdq.net (JDeats) wrote in message news:<b0******* *************** ****@posting.go ogle.com>...

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.

[JamesMason]

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

je****@pdq.net (JDeats) wrote in message news:<b0******* *************** ****@posting.go ogle.com>...

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]

JamesMason <jm****@funnyde light.co.uk> wrote:

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.)

--
Jon Skeet - <sk***@pobox.co m>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too

[Jon Skeet]

JamesMason <jm****@funnyde light.co.uk> wrote:

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.)

--
Jon Skeet - <sk***@pobox.co m>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too

[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.

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.)

[Jon Skeet]

JamesMason <jm****@funnyde light.co.uk> wrote:

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.
--
Jon Skeet - <sk***@pobox.co m>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too