Heads up! This blog post is actually a reading log. I'm spending 30 minutes every day (more or less) reading C# via CLR by Jeffrey Richter and taking notes as I read it. This is tracked as a series on DevTo so you can read all parts of the series in order.

C# via CLR Reading Log 3: Chapter 1

And now we arrive to the section titled "IL and Verification." The section started off by asserting that the IL is a stack-based language, meaning that instructions and pushed onto and popped off a stack. The next sentence in this chapter immediately befuddled me.

Because IL offers no instructions to manipulate registers, it is easy for people to create new languages and compilers targetting CLR.

I didn't really understand this portion. I mean, I know what a register is (a tiny thing that stores data, lol) and I understand what it means to not have instructions to manipulate registers (no way to put thins in registers or retrieve them), but the leap to that making it easy for people to create new languages and runtimes confused me.

I wanted to research this further -- but here I arrived at the most annoying position anyone can be in. I didn't know how to ask the question that I wanted to ask. I ended up getting lucky by Googling "no register manipulation CLR" and finding this StackOverflow post where someone had asked the exact same question I had. I am not alone, woot!

My luck gets even better. Someone had posted an answer. They clarified that having register support would make the CLR more CPU specific. This makes sense because each CPU has a different set of registers and semantics for using them. By abstracting away these details, the CLR is more adaptable to new languages and compilers.

The book goes on to discuss another benefit of the CLR that is mentioned in the heading title: verification. Verification examines IL code and ensures that it is safe. The book outlined that verification checks for things like the number of parameters passed to a method, that return types are used correctly, and more. The examples listed all seemed like type-checking to me so I wondered why this process wasn't just called type-checking.

This section of the book continued discussing the difference between safe code (doesn't access memory at a particular address) and unsafe code (accesses and manipulates memory at the address) and different tools for disassembling and generating native code from assemblies. I tend to get a little bored with books like this when they walk into discussion around tooling.

I'll boldly admit that I skipped through the next few pages, which covered more tools and concepts related to them, and found myself in the section titled "The Common Language Specification." Now we're back to territory I am comfortable with!

The book once again made a reference to COM --- I really should Google what this is. And posed the following analogy: COM (whatever that is, lol) allows different languages to communicate with each other. That's a pretty general concept I'm comfortable with (but I still want to get into the nitty gritty of COM). The CLR facilitates the same goal by allowing different languages to share types and object references.

There's a problem with this though. Not all programming languages share the same approach to types. Whether it is how large integers are represented or whether methods support a variable number of parameters, each programming language has different levels of supportability for language features. The Common Langauge Specification outlines the minimum set of features that compilers targetting the CLR must support so that types and objects can be unified appropriately.

And that's it for the 30 minutes. In the next reading log, I'll be diving into the oft-proclaiming Chapter 2...