6

I am reading CLR via C# and came across this sentence in the first chapter and I did not understand what exactly it meant.

Full line here:

because IL offers no instructions to manipulate registers, it is easy for people to create new languages and compilers that produce code targeting the CLR.

What does it mean?

I ventured a guess that it means IL is a bit low level, but not too low so that it is easy to create languages on top of it.

7

They are saying that allowing a language to use registers ties it closer to a particular CPU architecture. because the CLR and IL have abstracted this complication away for you, it is 'easier' to create more fully featured applications like compilers, faster and more error free. because you are never worried about the details of whether your code will be portable beween CPUs, allowing you to focus on adding features to your programs.

  • 3
    To add a little more details: certain parts of the compiler, collectively known as "code generation" (or "codegen"), are found (learned by decades of compiler writers) to be tightly tied to particular CPU architecture, but had little influence on language design. What that means is that it would be silly for language designers to tune a language's syntax specifically for a particular CPU architecture, as long as such gains can be realized entirely on the heroic efforts of the "codegen" designers. This lead to a division of labor between the "front-end" and "back-end" of a compiler. – rwong Oct 5 '13 at 4:55
  • 1
    @rwong and by stating that no register instructions are included in the IL they are in effect saying they have done a lot of hard work for you already. – Andyz Smith Oct 5 '13 at 5:16
  • 2
    You're assuming registers must be registers of the underlying hardware. There register-based VMs too, whose registers are "virtual" in that they're defined by the VM, not the underlying machine. This kind of VM is just as hardware-independent as stack-based VMs. Ask the Lua guys, for example. – user7043 Oct 5 '13 at 7:35
8

I read this to refer to the choice of execution model, not to exposing lower-level details of the hardware architecture. The CLR is primarily a stack machine, meaning opcodes operate on a stack. The other common option in VM design space is the register machine, where a (usually unlimited) set of virtual registers is manipulated instead. These registers are an abstraction provided by the VM (much like the stack in the alternative), so it is hardware-independent and has to be mapped to hardware registers for faster execution. Examples are the Lua VMs (both the reference implementation and LuaJIT), Dalvik, and the experimental (for other reasons) Python VM Falcon.

If my reading is correct, the remarks simply refers to the fact that it's a bit easier to generate stack opcodes from an AST than it is to generate register opcodes. On a stack VM, each (or at least most) AST nodes can generate opcodes like this:

child1.codegen()
...
childN.codegen()
emit(OPCODES_FOR_THIS_OPERATION)

for example, for addition:

lhs.codegen()
rhs.codegen()
emit(ADD)

In contrast, a register-based VM needs to carry around at least some state to manage which register all the temporary values are put in. And if it wants to avoid using far too many registers, some slightly non-trivial optimizations are needed (to re-use registers, or more generally perform register allocation).

  • interesting. certainly didn't know all that. so actually the quote could be more specific. " because IL offers no instructions to manipulate registers, but instead offers instructions to maniplate stack-based 'virtual registers' it is easy for people to create new languages and compilers that produce code targeting the CLR." – Andyz Smith Oct 5 '13 at 14:13

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.