The next release of the .NET Framework will include both 32- and 64-bit native support. Christopher Brown discusses how developers writing managed code today will be able to easily port and, in many cases, just copy existing applications to this new environment.
MSDN TV: 64-bit Common Language Runtime and the .NET Framework
About The Author
Eugenia Loli
Ex-programmer, ex-editor in chief at OSNews.com, now a visual artist/filmmaker.
Follow me on Twitter @EugeniaLoli
the .net framework should have been designed from the ground up as a 64bit CLR instead of a 32bit CLR…
Yeah, that’s it. 😉
I’m still not sure why 64-bit platforms are seen as being such a godsend. I mean, increasing the register size is a nice way to speed up certain operations, but going from 32 to 64 isn’t really going to fundamentally change the way the typical user does things, and it won’t have much of a visible impact on their computing experience.
The .NET CLR is totally independent of the register size of the target machine. But of course the first implementation of the CLR spec had to target a very popular processor architecture such as x86.
I think it would be much more interesting to make the CLR JIT-Compiler emit code for SSE2 or AltiVec. The performance gains would be orders of magnitude bigger.
But of course this is much more complex than just doubling the size of the adress registers, so we will have to wait a bit longer…
If .net code is only portable “in many cases” what the hell is going on? Didn’t M$ say the CLR would allow .net code to run on anything (like JVM)?
Do any Java applications have porting issues????
It is portable. Look at the http://www.microsoft.com/downloads/details.aspx?FamilyId=3A1C93FA-7… mono” rel=”nofollow”>http://www.go-mono.com/”>mono, <a href=”http://www.dotgnu.org“>portable.net projects.
These support (at varying levels): Windows, Linux, Solaris, NetBSD, FreeBSD, and MacOS X. The portable runtime engine has been tested on the x86, PowerPC, ARM, Sparc, PARISC, s309, Alpha, and IA-64 processors. Rotor has been tested on PowerPC and x86 processors. Mono is x86 only, as far as I know.
> Mono is x86 only, as far as I know.
There is nothing inherently platform dependent in the Mono Runtime. In fact it is designed to be quite platform independent. But the mono team does not have the resources to maintain many different architectures while they implement the remaining parts of the .NET Framework Class Library. If e.g. IBM or Apple were to spend some money on a PPC port, it would be quite easy to make mono run on ppc.
nice stuff. too bad that widbey will be release in 2K4. Can’t wait for .NET 2.0 and C#’s generics :-))
> If .net code is only portable “in many cases”
> what the hell is going on?
.NET apps have been portable since to 64-bit systems the very first release. You just don’t get any advantages yet to running on a 64-bit machine. The compiled x86 CLR is not portable to other platforms except those that can emulate x86 like IA64 and x86-64. The CLR has to be ported to every platform (just like a JVM)
1) If you want instant gratification, one can look at J2SE 1.4.2 for Itanium, which does the job quite nicely.
2) Whats the story with the x86-64 port? will CLR be ported to that or will it be treated like the red head step child of the family?
3) Mono is split into two areas, JIT and Interpreter. JIT only supports x86 at this point in time, however, the Interpreter does support Linux/x86, Linux/PPC, S390 and StrongARM. Lets hope with a bit of help, JITs can be developed for those archictectures too.
4) John Caroll, who some people regard as a “Microsof sell out” has said in many of his articles that althought it doesn’t provide 100% portability, it does however provide a greater degree of easy portability.
5) Having used Eclipse, which is based around SWT, IMHO, if there is a way to go in the future, maybe that is the best avenue. Considering that one would need to redesign the interface for each platform as each platform has a different HIG and Look ‘n Feel, I have no issues with SWT.
6) SUN and IBM should push the adoption of Java + SWT for use in general purpose applications. In terms of programs that need things like pointers, that can easily be done by pushing that code out into modules/plugins in native code and thus simply link from managed to unmanaged code via JNI. This would allow much more easier portability of applications from one platform to another.
If .net code is only portable “in many cases” what the hell is going on?
If your code makes a lot of calls to native interfaces, it’s likely that you’ll have a few issues porting to another platform. If you stick pretty close to the CLR, it’s unlikely you’ll have many problems at all, unless, for instance, you’re trying to run the code on a platform that doesn’t have a complete .Net implementation (which is most of them).
Didn’t M$ say the CLR would allow .net code to run on anything (like JVM)?
It can, if the code is completely written to the stay within the CLR and not drop down to native code. Of course, you have to have a runtime for the platform (like JVM) that is also compatible.
Do any Java applications have porting issues????
Yes, but as time goes (now that Java’s what, 10 years old?) they reduce the number of cases where porting issues exist within the actual specifications of Java (ie where porting issues should not). There will still be porting issues if you’re writing native code that interacts with Java, since you’ll have to port the native code as well, and make sure that the interfaces remain the same (from the Java app’s perspective). Not to mention the general issue of the user interface not being consistent with the platform, though that is also being addressed.
the .net framework should have been designed from the ground up as a 64bit CLR instead of a 32bit CLR…
That sounds like a brilliant move. Produce a purely 64-bit CLR that runs on only a small selection of processors.
Rich Steiner,
What exactly is OS2200..?!
You don’t design code for 64-bit from the ground up. Well, not unless you’re writing an OS and want to use 64-bits to do some single-address space thing. What exactly would you do? Its not like you get any extra performance by assuming 64-bits rather than 32-bits. All that matters is that your code is 64-bit clean, mainly that you don’t assume that you can fit a pointer into an int.
So the article wasn’t talking about the .net application, but talking about the actual virtual machine. Which obviously has to be processor dependant since it converts the virtual .net bytecode into machine code.
Silly me.
Formerly Sperry UNIVAC 1100-series mainframe systems, still used quite heavily in the airline industry and also by the US government. 36-bit word-oriented architecture.