From e839d04a2f8f44118addb4e99a93a098989505fe Mon Sep 17 00:00:00 2001 From: Torsten Ruger Date: Sun, 6 Jul 2014 20:57:50 +0300 Subject: [PATCH] layers and passes --- _posts/2014-07-05-layers-vs-passes.md | 53 +++++++++++++++++++++++++++ 1 file changed, 53 insertions(+) create mode 100644 _posts/2014-07-05-layers-vs-passes.md diff --git a/_posts/2014-07-05-layers-vs-passes.md b/_posts/2014-07-05-layers-vs-passes.md new file mode 100644 index 0000000..7bbb9d3 --- /dev/null +++ b/_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. \ No newline at end of file