RTCG Meeting Notes, 22 May 95

In this meeting we talked about the language features that our language needs to have to support runtime compilation. We came up with the following requirements:

Explicit BEGIN and END for dynamic regions.
It should be possible to mark individual parts of data structures e.g. record fields as dynamic or static. For a record of two fields, for instance, it should be possible to have one field static and the other one dynamic.
We do not want to support marking some data as static inside a region. All that should be determined on entry of a region.
We should support nesting of regions.
Regions should have some sort of single entry property. As a first shot, we will disallow goto's into regions.
Function calls to statically known functions out of regions should be allowed.
The language construct marking data as static or dynamic should provide robustness. The default assumptions should be safe.

There was some discussion on how the identification of data as static or dynamic should be put in the language. One possibility is to make the syntax like the storage allocation specifiers in C. Another one is using specific operators to identify some data as static or dynamic. The operator approach might be ugly at times. The example of an array of records of two fields one of which is static the other dynamic would require going through a loop and setting the fields appropriately. An acceptable solution might be setting a default for the whole array and then only modify the elements and fields necessary.

The second topic was going back to last week's meeting and figuring out how the optimization of the guards in SPIN could be done. Craig proposed that the guard code could be optimized if we have define a little language in which the guards are expressed. Then they are implemented by a little interpreter. That interpreter would use the source code (or some derived IR) to execute the guards. As its input (the IR) would be static it could be optimized away into a compiler, i.e. the guard code would essentially be runtime compiled in a decision tree. There is currently one problem with that scenario. The main loop of such an interpreter would look like that: (interpreting the source tree)

t := root;
while ... do
  if (t.eval_expr) then
     t := t.left
  else
    t := t.right
  end
end

Currently at the end of an IF a merge would be done which would make the t dynamic and no compilation into a decision tree would result. Adding a special annotation to the IF to advise that the two branches should not be merged could solve the problem. Instead of fixing the loop unrolling in that way a recursive implementation of the interpreter could be used if unrolling of recursion were handled well. This needs to be looked at more.

ausland@cs.washington.edu