On Wed, 03 Dec 2008 18:20:53 +0100
Hadron <hadronquark@xxxxxxxxx> wrote:
> "Michael B. Trausch" <mike@xxxxxxxxxx> writes:
> > If you're an experienced programmer and you already know your way
> > around IDEs generally, you don't need something that is going to
> > hold your hand with VS---I'd recommend CLR via C#, 2nd Ed., which
> > is quite excellent. It's the third book I own from MS Press, and
> > strangely enough, it's very nice.
>
> And when applied to Linux systems the CLR is still the CLR?
>
> I find it hard to see the meeting point of .net and mono.
>
> Is mono a small open source subset? Can .net plugins contribute to the
> CLR and be accessible via Mono and the CLR?
>
> I dont pretend to be an expert here and the water is somewhat mirky at
> times.
The CLR ("Common Language Runtime" is the combination of the virtual
environment and an extreme subset of the class libraries that ship with
either Microsoft's .NET Framework or Mono (or GNU Portable.NET). The
CLR includes the common type system which provides a set of base types
from which one can build, including System.String, and System.Int32.
It includes a subset of the libraries in the System namespace.
Both Microsoft and de Icaza's implementations superclass the standard.
Mono provides many of Microsoft's extensions, as well as quite a few of
its own, including GtkSharp, the Mono.Posix class library, and other
things.
The core of the CLR, though, is the IL virtual CPU. Like Java's JVM,
the IL virtual CPU executes a series of opcodes. At a method-at-a-time
level, the IL virtual CPU translates methods into the current
platform's underlying machine language (with optimizations) such that
the IL virtual CPU doesn't have to interpret it at all in the future.
This is unlike the JVM's virtual CPU, which acts very much like a
traditional hardware-based CPU, stepping through instructions and
maintaining its own state often throughout the code. The CLR also
provides a set of standards for use by compilers that wish to target
it, such as the calling conventions of IL methods, and so forth.
Just as an example to compare, here's an implementation of "Hello,
World" written in C:
----- Begin program listing
#include <stdio.h>
int
main(int argc, char *argv[]) {
printf("Hello, world!\n");
return(0);
}
----- End program listing
So, when run through "gcc -S hello.c", a file "hello.s" is produced,
which is the assembly-language listing of the program. It contains
data storage for the "Hello, World!" string, the main() function, and
some extra information that GCC uses. You can see the full disassembly
by copying the above program into "hello.c" and using the gcc
invocation above. The main() function looks like this, though
(subsetted output of "objdump -d hello" on the compiled output file,
which is actually easier to read than the gcc-generated assembly file):
----- Begin assembly listing
000000000040050c <main>:
40050c: 55 push %rbp
40050d: 48 89 e5 mov %rsp,%rbp
400510: 48 83 ec 10 sub $0x10,%rsp
400514: 89 7d fc mov %edi,-0x4(%rbp)
400517: 48 89 75 f0 mov %rsi,-0x10(%rbp)
40051b: bf 1c 06 40 00 mov $0x40061c,%edi
400520: e8 d3 fe ff ff callq 4003f8 <puts@plt>
400525: b8 00 00 00 00 mov $0x0,%eax
40052a: c9 leaveq
40052b: c3 retq
40052c: 90 nop
40052d: 90 nop
40052e: 90 nop
40052f: 90 nop
----- End assembly listing
Now, let's take a look at the same program, written in C#:
----- Begin program listing
using System;
public static class EntryPoint {
public static int Main(string[] args) {
Console.WriteLine("Hello, World!");
return(0);
}
}
----- End program listing
Compile this by saying "gmcs hello.cs", and the resulting output file
will be "hello.exe". On Ubuntu (Hardy or Intrepid, I don't remember
when this was introduced as default behavior) you can simply say
"./hello.exe" to invoke the program; if that doesn't work you say "mono
hello.exe" to invoke it. Now, we disassemble it using "monodis", and
we see some assembly information, the EntryPoint class that we've
defined, and the Main method, which contains:
----- Begin assembly listing
.method public static hidebysig
default int32 Main (string[] args) cil managed
{
// Method begins at RVA 0x20ec
.entrypoint
// Code size 12 (0xc)
.maxstack 8
IL_0000: ldstr "Hello, World!"
IL_0005: call void class
[mscorlib]System.Console::WriteLine(string)
IL_000a: ldc.i4.0
IL_000b: ret
} // end of method EntryPoint::Main
----- End assembly listing
The assembly language listing for both show what the instructions that
execute on the CPU look like. To load a string on the IL virtual CPU,
you 'ldstr'---on the native CPU, you assign pointer to one of the CPU's
registers and call another pointer which will deal with it. Here in
IL, you actually call the method by name; that's what the "call void
class" line does. "[mscorlib]" is the assembly that the method is
located in, which in this case is the core library for the framework,
which provides the System type classes and structures and certain
things like the System.Console class.
BTW, "cil", which you see in the assembly listing for the Mono
implementation of Hello, World, means "common intermediate language",
which is the name of the assembly language for the IL virtual CPU.
The files used by the CLR to run software (.exe and .dll files which
are specially formulated, usually without any native code contained
within them) are the same file format for every implementation of the
CLR. Therefore, they're portable. The hello.exe file I just created
with my gmcs compiler will turn around and run on Windows under
Microsoft's .NET, for example. If I write a class library, as long as
I don't use P/Invoke or otherwise do anything that makes the assumption
that I am on a UNIX-like system (or GNU/Linux in particular), my class
library will be portable to Windows, as well, without recompilation.
Does this help at least some?
--- Mike
--
My sigfile ran away and is on hiatus.
http://www.trausch.us/
|
|
