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...
Top comments (7)
COM is a way to interop between languages. My experience with it had been in the context of Windows machines, like with older tech. You could consume COM APIs within .NET or Visual Basic macros in Excel.
Here's a good answer with more detail: stackoverflow.com/questions/748355...
Cool link -- thanks! Will dig into this more.
Stackoverflow is a savior in most instances when you are still struggling about the language, actually it has helped often when am time bound and the solution is needed.
My experience with StackOverflow is descriped beautifully in this xkcd:
I've been praying for a new edition of CLR via C# for ages!😤
...where you find the exact question is already posted on StackOverflow... by yourself, last time you encountered the problem 😶
...and then you realize the question is for an older version of whatever framework/package you are using and no longer applies. ragequit