Which processors are capable of running Common Intermediate Language(CIL), formerly known as Microsoft Intermediate Language (MSIL)? Clearly any machine that can run Microsoft Windows with .net qualifies as well as machines targeted by the Mono project.
It would appear that the .NET Micro Framework has the ability to target other processors not covered by the above, but it is not clear to me that it uses CIL.
Does anyone have a list of which processors are capable of running a program in CIL and or interpreting C# directly (as the .NET Micro Framework appears to do)?
EDIT to clarify, I understand that CLI is not executed directly on the metal but rather by a a runtime engine. So for this question any processor with a runtime engine that executes CIL qualifies.
None. There is no processor that runs CIL - CIL is to my knowledge ALWAYS translated to another form of machine code.
I think there is a CIL processor "floating around" are research project, but so far not seen in the real world.
The .NET Micro Framework doesn't allow processors to interpret CIL directly. It is simply an even more lightweight interpreter that runs on embedded hardware instead of requiring a full PC architecture. It's like .NET Compact Framework but with a smaller footprint. To look at the architectures that this supports:
.NET Micro Framework Hardware
Afaik, TomTom is right.
They call it Intermediate for a reason... it is between the programmer's language and the processor's language.
An interesting thought, though - having a processor that runs CIL code.
I found two research processors that execute CIL natively much like the JOP does for Java Bytecode:
SCIL According to the paper it supports a subset of CIL, so the some portions of CIL will have to be emulated in subroutines. Honestly though the processor and paper do not look well put together.
DSP Core for Hardware Based CIL Machine This one looks more legitimate, however its designed with a very specific purpose in mind (DSP on a mobile phone).
Realize that these cores are meant for use with FPGAs. Sadly neither of them provided source code or bitfiles, so you will have to request more information from the authors if you actually want to use them.
On the .NET Micro Framework page it mentions a CLR which is what is running the CIL.
It includes a small version of the .NET CLR...
The supported platforms on mono-project.com list a few architectures.
Though be careful to test it before investing too much time.
The only guaranteed targets are those bundled with the Xamarin product.
In the past mono was missing floating point support on some ARM architectures which since has been added.
Related
I was willing to create an app for IntelAppUp store.I came across Cilk++.I was wondering how to use this C++ library in C # application while building a form based application?Any insight will be helpful
Cilk++ is unsupported. It has been replaced by Intel® Cilk™ Plus, which has been implemented by the Intel Composer XE C++ compiler (Composer XE 2011 or later), as well as in the "cilkplus" branch of GCC.
You'll need to be careful mixing Cilk Plus and C# forms. Cilk Plus provides an easy-to-use fork/join parallelism mechanism. Inside the parallel region, there's no way to predict which thread a piece of code will run on. You'll need to be aware of the limitations of C# forms and threaded applications. A good primer on the issues here is the article "Safe, Simple Multithreading in Windows Forms" available at http://msdn.microsoft.com/en-us/library/ms951089.aspx . You might also look at the QuickDemo example which shipped with Composer XE for Windows. Admittedly, QuickDemo is an MFC, not WinForms, based application, but it demonstrates many of the same issues.
- Barry Tannenbaum
Intel Cilk Plus Runtime Development
Suppose I have a software and I want to make cross-plataform plugins. You compile the plugin for a virtual machine, and any platform running my software would be able to run this code.
I am wondering if it is possible to use LLVM interpreter and bytecode for this purpose. Also, I am wondering if does make sense using LLVM for this purpose instead of something else, i.e. is it what LLVM was made for?
I'm not sure that LLVM was designed for it. However, I doubt there is anything that hasn't been done using LLVM1
Other virtual-machines based script engines are specifically created for the job:
LUA is very popular
Wikipedia lists some other Extension/embeddable languages under the Scripting language entry
If you're looking for embeddable virtual machines:
IKVM supports embedding JVM and CLR in a bridged mode (interoperable)
Parrot supports embedding (and includes a Python interpreter; mind you, you can just run python bytecode images)
Perl has similar architecture and supports embedding
Javascript supports embedding (not sure about the architecture of v8, but I guess it would use a virtual machine)
Mono's CLR engine supports embedding: http://www.mono-project.com/Embedding_Mono
1 including compiling c++ information to javascript to run in your browser...
There is VMIR (https://github.com/andoma/vmir) which is a LLVM bitcode interpreter / JIT engine that's intended to be embedded into other apps.
Disclaimer: I'm the author of it and it's still work-in-progress but works reasonable well.
In theory, there exist a limited subset of LLVM IR which can be portable across various platforms. You shall not specify alignments, you shall not bitcast pointers to integral types, you must avoid intrinsics, etc. Which means - you can't immediately use a code generated by a stock C compiler (llvm-gcc, Clang, whatever), unless you specify a limited target for it and implement sanitising LLVM passes. Another issue is that the bitcode format from different LLVM versions is not guaranteed to be compatible.
In practice, I would not go there. Mono is a reasonably small, embeddable, fast VM, and all the .NET stack of tools is available for it. VM itself is pretty low-level (as long as you do not care about the verifyability).
LLVM includes an interpreter, so if you can build this interpreter for your target platforms, you can then evaluate LLVM bitcode on the fly.
It's apparently not so fast though.
In their classic discussion (that you do not want to miss if you're a fan of open source, LLVM, compilers) about LLVM vs libJIT, that has happened long before LLVM became famous and established, the author of libJIT Rhys Weatherley raised this particular issue, he stated that LLVM is not suitable to be embedded, while Chris Lattner, the author of LLVM stated that otherwise, it is modular and you can use it in any possible fashion including embedding only the parts you need.
We have a business logic that works with the file systems on OS that we want to implement on both Linux and Windows platforms. The language we have selected is Python for Linux and C# for Windows. GUI is not a priority for now. We were looking for ways to abstract the business logic in a way that we dont have to repeat the business logic (ofcourse I understand since it is related to file system, some code will differ from platform to platform).
Any ideas on how to implement it? Is C/C++ the only option. We dont want to use Java.
Thanks,
Pranz
yea, pick a common language for the logic first. Punting down in to C/C++ pretty much eliminates any of the real values to development that the Python and C# languages provide. Done write, MOST of your logic will be "Business Logic" with the rest glue to external services (i.e. databases, etc.).
So, you should pick a portable environment from the get go. Dropping down to C/C++ and linking it in is a viable alternative, but most likely not worth the time.
Mono is an option you'll probably want to look into.
Quote from the site for easy explanation:
Mono is a software platform designed to allow developers to easily create cross platform applications. Sponsored by Novell, Mono is an open source implementation of Microsoft's .NET Framework based on the ECMA standards for C# and the Common Language Runtime. A growing family of solutions and an active and enthusiastic contributing community is helping position Mono to become the leading choice for development of Linux applications.
Either use Mono or Python.
Mono allows you to run C# .NET code on both platforms. Python can be executed on both platforms already.
Qt has cross-platform libraries for all sorts of things, including UI and file system. It does, however, use C++.
Is it possible to make an operating system using VB.NET?
Yes it is possible to make an operating system using vb.net.
You've got a serious bootstrap problem. Compiled VB.NET code cannot run without the services of the CLR and the JIT compiler. Existing implementations of it (mscorwks.dll and mscorjit.dll for example) have a heavy dependency on services provided by an operating system. You'll have to write your own, that's non-trivial to put it mildly. In addition, many classes in the framework rely on P/Invoke to directly call a Windows API function. Very basic classes like Console, Control, FileStream, Socket. You'll have to replace those too. That's where Singularity was stuck last time I saw a video of it.
The "starter kit" for any project like this is Rotor. That's how Mono got started. Take a look at what your in for, focus on the Platform Adaption Layer (PAL). Needs to be written in unmanaged C/C++ in its current form though.
It has been done (well C# at least, but since they are both CLR languages...)
It's called Singularity by Microsoft Research.
http://en.wikipedia.org/wiki/Singularity_(operating_system)
https://github.com/CosmosOS :::: here is the Answer; Cosmos Allows you to develop your own kernal with c#
Yes, it is possible.
But first you will have to identify what an operating system is; and then define what would you want in your operating system? An operating system does a lot of work on the background as well as on the foreground; there are applications, memory, threading, network, ports, a separate world that make things work.
I would agree with Aviad that probably your OS may be called a .NET CLR, but thats what that would be called. An answer to your question is that it is possible provided that you define your OS and probably limit yourself to what you really require.
No!
Unless you re-define what an operating system is and make the problem fit the solution. This has been standard practice in this industry for decades. Given the right definition of Operating System, you can even use Esperanto to write it:) So what is your definition of Operating System?
Yes, but that would not be easy. Or hard, as a matter of fact. It would be insanely difficult! You would have to write a Visual Basic interpreter (in asm or c), then you would need to implement System and a lot of other CLR stuff. What you may be looking to do is create a virtual OS. This would mean that it lays over the Windows gui and acts as an interface. Good luck.
Since MS appears to have killed Managed JavaScript in the latest DLR for both server-side (ASP.NET Futures) and client-side (Silverlight), has anyone successfully used non-obsolete APIs to allow scripting of their application objects with JScript.NET and/or can explain how to do so? A Mono/JScript solution might also be acceptable, if it is stable and meets the requriements below.
We are interested in upgrading off of a script host which uses the Microsoft JScript engine and ActiveScript APIs to something with more performance and easier extensibility. We have over 16,000 server-side scripts weighing in at over 42MB of source, so rewriting into another scripting language is out of the question.
Our specific requirements are:
Noteably better performance than the Microsoft JScript (ActiveScript) engine
Better runtime performance and/or
Retention of pre-parsed or compiled scripts (don't reparse on every run)
Lower or equal memory consumption
Full ECMA-262 ECMAScript compatibility
a little porting can be tolerated
Injection of custom objects into the script namespace
.NET objects (not a hard requirement)
COM objects or COM objects wrapped in .NET
Instantiation of COM objects from Script
à la "new ActiveXObject(progid)"
Low priority given the preceeding
Include files
Pre-loading of "helper scripts" into a script execution context
An "include" function or statement (easy to create, given the above)
Support for code at global-scope
Execution of code the global scope
Retention of values initialized at global scope
Extraction of values from the global scope
Injection and replacement of values at the global scope
Calling of script-defined functions
with parameters
and with access to the previously initialized global scope
Source-level debugging
Commercial or Open Source Support
Non-obsolete APIs
I answered a similar question here. Have a look at IronJS, an implementation of JavaScript in F# running on the DLR.
Sooner or later, I imagine someone will write a DLR Javascript. I know that's not very convenient for you right now, but maybe you could start the project. I suspect it would have a better cost/benefit analysis to using JScript.NET.
If moving away from .NET and Microsoft is ok for you then you should try Mozilla's Rhino. It is an open-source implementation of JavaScript written entirely in Java. Alot of modern server side js libraries target this platform.
I have used CSScript.net as it will allow you to run C# as a scripting platform. From the site:
CS-Script combines the power and
richness of C# and FCL with the
flexibility of a scripting system.
CS-Script can be useful for system and
network administrators, developers and
testers. For any one who needs an
automation for solving variety of
programming tasks.
CS Script satisfies all the conditions that you laid out. I have used it in production as a substitute for Boo it has performed really well. You can see it in action here.
The use of Com interop means you are limited to an MS solution Java and Opensource want as little as possible to do with it.
I dont see any solution that supports all your requirements either you ditch all the COM/.NET stuff and go Java (Rhino) /Linux/Open source or you question the use of Javascript as your server language even in the Linux world we use PHP/Python/Ruby more on the server if we cant run Java. Your not going to see big performance gains with Java script as the language is the main barrier.
I wouldnt count on people writing a new DLR as server Java script is dying fast.
Considering you want performance ,what about F# , Microsoft will keep the Jscript engine supported for at least 5 years giving you time to create new stuff in F# while you slowly migrate the code.
Have you seen ROScript?
http://www.remobjects.com/script.aspx
Supports both PascalScript and ECMAScript (Javascript) syntax
The Jurrassic-Engine is alive and kicking.
From their codeplex site:
Supports all ECMAScript 3 and ECMAScript 5 functionality, including ES5 strict mode
Well tested - passes over five thousand unit tests (with over thirty thousand asserts)
Simple yet powerful API
Compiles JavaScript into .NET bytecode (CIL); not an interpreter
Deployed as a single .NET assembly (no native code)
Basic support for integrated debugging within Visual Studio
Uses light-weight code generation, so generated code is fully garbage collected
Tested on .NET 3.5, .NET 4 and Silverlight