Is it Possible to build a Processor which understands MSIL code.
-
Note : This one is Extreme Hypothetical dream Is it possible to build a CPU that understands Itermediate Language straight away. ( No JIT, No unmanaged) What could be the blocking factor's if we can't take it to the next Consumer Electronic Show (CES) ;P
Regards, Vythees Miles to go before sleep...
I think it would totally defeat the purpose. MSIL looks like assembly for a reason, because it's a simple way to specify RISC instructions. Those RISC-like instructions are translated into actual CPU instructions optimized for the CPU it's running on. If you want to change the way it optimizes, that means new hardware, as opposed to new software which is just bits. Microsoft is experimenting with an entirely managed OS, all code would have to be managed code, i.e. MSIL instructions. They call it Singularity (awesome name), it's one of their research projects. I think this is the better approach. GC is built on top of Windows memory management, but in singularity, GC is the memory management model. This is one of its major optimizations.
-
Note : This one is Extreme Hypothetical dream Is it possible to build a CPU that understands Itermediate Language straight away. ( No JIT, No unmanaged) What could be the blocking factor's if we can't take it to the next Consumer Electronic Show (CES) ;P
Regards, Vythees Miles to go before sleep...
-
Note : This one is Extreme Hypothetical dream Is it possible to build a CPU that understands Itermediate Language straight away. ( No JIT, No unmanaged) What could be the blocking factor's if we can't take it to the next Consumer Electronic Show (CES) ;P
Regards, Vythees Miles to go before sleep...
Cool question… What about FPGAs? http://en.wikipedia.org/wiki/FPGA[^]Just make sure the IL commands & assumed services are built and turn on the juice. However, I’d imagine you’d need an FPGA the size of which doesn’t exist to execute even the smallest app. Full disclosure: I’ve yet to work with FPGAs, so this idea might be trash. I’ve been drooling over them for a while. I can just imagine writing an app that translates into “circuitry”… then the headache comes when thinking about tracing & debugging.
-
Note : This one is Extreme Hypothetical dream Is it possible to build a CPU that understands Itermediate Language straight away. ( No JIT, No unmanaged) What could be the blocking factor's if we can't take it to the next Consumer Electronic Show (CES) ;P
Regards, Vythees Miles to go before sleep...
Unlike Java bytecode; .NET IL is designed to be JIT-compiled, not interpreted. For example, .NET has only a single "add" instruction, which means integer addition or floating-point addition depending on the argument types. Also, each entry on the execution stack (always 32-bit for Java) can be arbitrarily large in .NET (as large as the largest struct). So you'll have a very hard time mapping that to hardware registers. For this reason, any .NET IL interpreter (whether hardware or software) would be highly inefficient. AFAIK even Mono's "mint" (the interpreter Mono uses on platforms for which they don't have a JIT compiler) does not interpret .NET IL directly, but first translates the IL into another intermediate language.
-
I couldn't care less about a processor that runs MSIL. The one I really want to see is the proc that can run encrypted code natively, without first decrypting it.
A guide to posting questions on CodeProject[^]
Dave Kreskowiak -
Note : This one is Extreme Hypothetical dream Is it possible to build a CPU that understands Itermediate Language straight away. ( No JIT, No unmanaged) What could be the blocking factor's if we can't take it to the next Consumer Electronic Show (CES) ;P
Regards, Vythees Miles to go before sleep...
I doubt that this would meet what you dream of, but there is the .NET Micro Framework. http://www.microsoft.com/netmf/default.mspx This gives you a small embedded processor which is programmed using the .NET Framework (or a portion of it). The micro controllers of today approach a system on a chip of yesterday. Many only need power to a couple pins to become workable and the remaining pins become inputs and outputs.
-
How would that work? Everyone would have to use the same encryption key and then everyone could decrypt the code leaving you with no protection.
I didn't say I knew how it would work. But I did say it would be nice if you didn't have to decrypt it to run it. Just a wild thought with no concern of how it would work or its implementation.
A guide to posting questions on CodeProject[^]
Dave Kreskowiak -
Note : This one is Extreme Hypothetical dream Is it possible to build a CPU that understands Itermediate Language straight away. ( No JIT, No unmanaged) What could be the blocking factor's if we can't take it to the next Consumer Electronic Show (CES) ;P
Regards, Vythees Miles to go before sleep...
Something a bit similar was done in in the 1980s with the Pascal MicroEngine: http://en.wikipedia.org/wiki/Pascal_MicroEngine
-
Have you checked out Singularity at MS Research. It doesn't run MSIL natively, but is a completely CLR(ish) O/S, with many improvements. Very Radical. Singularity[^]
Or even better is the COSMOS project. They include a compiler to turn IL into ASM, but everything else is written in C#
-
Note : This one is Extreme Hypothetical dream Is it possible to build a CPU that understands Itermediate Language straight away. ( No JIT, No unmanaged) What could be the blocking factor's if we can't take it to the next Consumer Electronic Show (CES) ;P
Regards, Vythees Miles to go before sleep...
-
Note : This one is Extreme Hypothetical dream Is it possible to build a CPU that understands Itermediate Language straight away. ( No JIT, No unmanaged) What could be the blocking factor's if we can't take it to the next Consumer Electronic Show (CES) ;P
Regards, Vythees Miles to go before sleep...
A few thoughts: First - The part you would want to build into the CPU would be the CLR - it's the part that interprets the MSIL code (same job as the bytecode interpreter in Java), creates the proper assembly level code for the machine to run and kicks it off. Second - Make the JIT compiler and framework dlls ROM based. Everything in .NET runs compiled to MSIL, including ASP.NET, the JIT is responsible for detecting that an ASP.NET file has changed since it was last run and recompiling it to MSIL. This is what gives you the capability of changing an ASP.NET page on the fly and having the newly saved version run next time the page is hit. Third - Same problem as someone else mentioned, you would be stuck using whatever version of the .NET Framework that was designed to use CLR that you have in the CPU and the JIT compiler and framework dlls in your ROM. The only way to upgrade your Framework version would be to upgrade your CPU and ROM chips. This also means that you would be prohibited from running any third party software that requires a different version of the .NET Framework. Requiring previous framework versions shouldn't be a problem as long as you stick to 2.0+, but anything that requires a newer version will not work. But then this is generally why they don't design the hardware to the OS, but the OS to the hardware. Well designed hardware should be capable of supporting more than 1 OS.
Kevin Rucker, Application Programmer QSS Group, Inc. United States Coast Guard OSC Kevin.D.Rucker@uscg.mil "Programming is an art form that fights back." -- Chad Hower
-
A few thoughts: First - The part you would want to build into the CPU would be the CLR - it's the part that interprets the MSIL code (same job as the bytecode interpreter in Java), creates the proper assembly level code for the machine to run and kicks it off. Second - Make the JIT compiler and framework dlls ROM based. Everything in .NET runs compiled to MSIL, including ASP.NET, the JIT is responsible for detecting that an ASP.NET file has changed since it was last run and recompiling it to MSIL. This is what gives you the capability of changing an ASP.NET page on the fly and having the newly saved version run next time the page is hit. Third - Same problem as someone else mentioned, you would be stuck using whatever version of the .NET Framework that was designed to use CLR that you have in the CPU and the JIT compiler and framework dlls in your ROM. The only way to upgrade your Framework version would be to upgrade your CPU and ROM chips. This also means that you would be prohibited from running any third party software that requires a different version of the .NET Framework. Requiring previous framework versions shouldn't be a problem as long as you stick to 2.0+, but anything that requires a newer version will not work. But then this is generally why they don't design the hardware to the OS, but the OS to the hardware. Well designed hardware should be capable of supporting more than 1 OS.
Kevin Rucker, Application Programmer QSS Group, Inc. United States Coast Guard OSC Kevin.D.Rucker@uscg.mil "Programming is an art form that fights back." -- Chad Hower
Thanks for the Insight. From the scalable point I agree that hardware targeting a specific framework would not be posssible for a general PC. Probably it could fit for specific task like, middleware broker, Routing, Message Filters devices. For this purpose I got a reply from Kirk Wood about .Net MicroFramework. Managed OS could be the possible way for targeting a general PC. I got a reply in this same thread from Patrix Fox about a project called Singularity. Note: Don't know how to refer those previous link in this thread. Sorry for Innconvinience.
Regards, Vythees Miles to go before sleep...