Internals of GCC (Commentary)

 

I'm just gonna go ahead and try to write on what little I understood from the podcast.

The stages of program compiling have been taught to us thoroughly on this course, what we did not learn about, and I find the most interesting about the GCC, is its so-called middle-end. Compilers are no longer a thing of magic for me, but they are definitely a wonder in their complexity. I do not pretend to thoroughly understand the works of every and all software architectures, or their compiling mechanisms.

But, this middle-end actually solves an issue I've been having with compilers. How does interconnectivity between the programming language and machine language works? Now what this particular component does, is that it already receives a CLR version of the introduced code, produced by the front-end.

The middle-end in turn passes a machine language version of the CLR into the back-end.

This means that, while the front-end is language dependent, the middle-end is language and architecture independent, and the back-end is language independent and architecture dependent.

Language Design and Implementation using Ruby and the Interpreter Pattern (Commentary)

 

I remember during my Software Architecture Course (imparted by Professor Ariel Ortiz, who imparts Compilers Design, Programming Languages, and was also my current boss' teacher) we were assigned a task for the interpreter pattern. Basically, we had to create a DSL for s-expressions (or something that looked like them) using the Ruby language, which was, in itself, a titanic task. I'm grateful this particular pattern was not a part of the curricula for the final exam.

Now, while taking this Compiler Design course, I wish the whole affair could be done using Ruby.

While examining some of the topics pertaining Compiler Design, I can't help but wonder some details that are reminiscent of the Programming Languages course. For one, I find Bison's syntax to be similar to s-expressions, switching of course parentheses for brackets. It still seems to follow some of the same convensions, each statement or line to be evaluated is accessed as a list, and through its indexes, values located at a certain place are evaluated as specified in the rules.

Another excercise Professor Ariel seems to be quite fond, is processing operator-first syntax with a basis on regular old operations.

It is to be expected that lisp-like syntax would have its advantages in designing compilers, it offers easy recursion, and the fact that the operator is written first, makes everything simpler to be processed by reducing the number of grammar elements.

Technical Overview of the CLR (Commentary)

  

Gotta get this out of the way:

For Java to be such a recurssion heavy language, I find it hard to believe that tailcalls are not a priority for the Java Virtual Machine.

While the article is pretty relentless in its critique towards the JVM, what I find the most interesting is the actual meaning of the CLR instructions, particularily those used in imperative programming languages such as our very own Deep-Lingo. It's good to take a look at the most primitive elements of programming languages such as structs, value types, type refs, and what comprises integers and other primitives.

I still have troubles comprehending something that was said in my compiler's course. We were told that every value that can be used, written, modified, and defined in Deep-Lingo is actually an Int32 type. Sadly, although very iluminating on the nature of intermidiate languages, this article failed to help me resolve (or understand) the issues  I've been having with this idea.

Moving away from confussion, the article is pretty clear in its definition of the diferent stacks used by CLI to handle variables, values, parameters, and instructions. Not that this stage of compiling has become crystal clear for me, but this piece definitely sheds some (frankly, much needed) light on what's next.