Is CIL assembly language and JIT assembler

Question

We know that the Common Intermediate Language (CIL) or (MSIL) is an object-oriented assembly language .

But does the Just In Time (JIT) really map each of these instructions to the opcodes core processor?

And if so , we can call CIL assembly language and JIT assembler

Note: Wikipedia does not list CIL as assembly language in its list of assembly languages

Answer 1

No, you cannot call CIL assembly language. The assembly consists of mnemonics for machine code instructions of a particular processor. A direct representation of 1s and 0s, which make the kernel code executable, but written in the text to make it easy for humans. Which is very similar to CIL:

• you cannot buy a processor that runs CIL
• CIL does not target a specific processor, jitter
• CIL adopts a stack-based execution model, processors are mostly registered based on
• CIL code optimized from its original form
• there is no one-to-one translation of the CIL instruction into the processor instruction

This last bullet is a key, constructive solution that makes CIL very different from bytecode, that CIL instructions are not type. There is only one ADD command, but processors have many versions. Concrete ones that accept byte, short, int, long, float, and double operands. Required because various parts of the processor core are used to complete the add. Jitter selects the correct one, depending on the type of operands that it outputs from previous CIL instructions.

Like the + operator in C #, it can also work with different operands. What really makes L significant in CIL is the language. Simple, but it just helps simplify jitter recording for him.

Answer 2

This question is about definitions, so let's define the terms correctly. Assembler language first:

Assembly language is a low-level programming language for computers, microprocessors, microcontrollers and other programmable devices in which each operator corresponds to one machine language instruction. The assembly language is specific to a particular computer architecture, unlike most high-level programming languages ​​that are usually ported to multiple systems.

Now CIL :

A common intermediate language is a human-readable programming language defined by a language defined by the Common Language Infrastructure (CLI) specification and using the .NET Framework and Mono. Languages ​​targeted at the CLI-compatible runtime are compiled into CIL, which is assembled into object code, which has a bytecode style format.

Well, this part is technically incorrect: for example, the C # compiler compiles directly to bytecode, it does not go through CIL (human-readable language), but theoretically we can imagine what is happening.

With these two definitions, CIL is an assembly language because each statement in it is compiled to one bytecode instruction. The fact that there is no physical computer that can execute this bytecode directly does not matter.

The definition says that every assembler language is "specific to a particular computer architecture." In this case, the architecture is a CLR virtual machine.

About JIT: the JIT compiler cannot be considered assembler: it does not translate 1: 1 from a human-readable form to bytecode, ilasm does this.

Answer 3

The line is actually quite blurry ... the arguments that I saw against calling CIL , the "assembler language" in practice can be applied practically to x86 / x86-64 .

Intel and AMD did not make processors that follow the assembly instructions in exactly the same way as for decades (if ever), so even the so-called "native" code is not much different from working on a virtual machine, whose byte code specified in x86 / x86-64 .

x86 / x86-64 are typical low-level developers who have access, so if we had to put our foot and call something in our ecosystem “assembly language”, it will win, and since CIL will end up requires that x86 / x86-64 instructions can run on the processor in this family, then there is a pretty strong case for it to really not “feel” how it should calculate.

So, in a sense , perhaps none of them can be considered "assembly language". When it comes to x86 / x86-64 , we almost never refer to processors that run x86 / x86-64 without translating it to something else (that is, whatever the microcode does).

To add another wrinkle, the way the x86 / x86-64 executes a given sequence of instructions can simply be changed by updating the microcode. A quick search reveals that Linux can even do this on its own in software !

So, I think, here are the criteria that can justify their placement in two separate categories:

• Does it matter that all the current machines that run the CIL are implemented in software?
• Does it matter that the same hardware can interpret the same x86 / x86-64 instructions differently after they are instructed to do this in the software?
• Does it matter that at present we have no way to bypass the microcode and issue commands directly to the physical units of x86 / x86-64 ?

So regarding the question “is CIL for assembler” the best answers I can give are “it depends” (for scientists) and “to a large extent” (for engineers).

Answer 4

CIL is more bytecode than assembly language. In particular, this is not a text-readable form, in contrast to assembly languages ​​(perhaps CIL also defines the format of bytecode files).

MSIL JIT is a virtual machine implementation for this bytecode. How an implementation (from Microsoft or from Mono ) translates CIL into machine code is a part of the implementation that does not matter to you (and given that Microsoft VM is probably the property and then will not tell you how to do it). I think that the mono-free implementation of CIL- software uses LLVM , so it may not be possible to translate each bytecode at a time, but probably completely methods or functions.