layers and passes

_posts/2014-07-05-layers-vs-passes.md

@@ -0,0 +1,53 @@
+---
+layout: news
+author: Torsten
+---
+
+I am not stuck. I know i'm not. Just because there is little visible progress doesn't mean i'm stuck. It may just feel like it though.
+
+But like little cogweels in the clock, i can hear the background process ticking away and sometime there is a gong.
+
+What i wasn't stuck with is where to draw the layer for the vm.
+
+### Layers
+
+Software engineers like layers. Like the onion boy. You can draw boxes, make presentation and convince your boss. 
+They help us to reason about the software.
+
+In this case the model was to go from ast layer to a vm layer. Via a compile method, that could just as well have been a 
+visitor.
+
+That didn't work, too big  astep and so it was from ast, to vm, to neumann. But i couldn't decide on the abstraction of the
+virtual machine layer. Specifically, when you have a send (and you have soo many sends in ruby), do you:
+
+- model it as a vm instruction (a bit like java)
+- implement it in a couple instructions like resolve, a loop and call
+- go to a version that is clearly translatable to neumann, say without the value type implementation
+
+Obviously the third is where we need to get to, as the next step is the neumann layer and somewhow we need to get there.
+In effect one could take those three and present them as layers, not as alternatives like i have.
+
+### Passes
+
+And then the little cob went click, and the idea of passes resurfaced. LLvm has these passes on the code tree, is probably 
+where it surfaced from.
+
+So we can have as high of a degree of abstraction as possible when going from ast to code. And then have as many passes 
+over that as we want / need. 
+
+Passes can be order dependend, and create more an more datail. To solve the above layer conundrum, we just do a pass for each
+of those options.
+
+The two main benefits that come from this are:
+
+1 - At each point, ie after and during each pass we can analyse the data. Imagine for example that we would have picked the 
+second layer option, that means there would never have been a representation where the sends would have been explicit. Thus
+any analasis of them would be impossible or need reverse engineering (eg call graph analysis)
+
+2 - Passes can be gems or come from other sources. The mechanism can be relatively oblivious to explicit passes. And they 
+make the transformation explicit, ie easier to understand. In the example of having picked the second layer level, one
+would have to patch the implementation of that transformation to achieve a different result. With pases it would be a matter
+of replacing a pass, thus explicitly stating "i want a non-standard send implementation"
+
+Actually a third benefit is that it makes testing simpler. More modular. Just test the initial ast->code and then mostly
+the results of passes.