anchor.diff:  project. The resulting Java application was integrated into the MC-3020 flow and
   used to generate C source for the MicrowaveOven example project. The source
   generated by Java mcmc was semantically identical to the source generated by the
  -current production version of mcmc and the behavior of the generated application
  +current production version of mcmc, and the behavior of the generated application
   was identical. This experiment has been leveraged to produce the following
   analysis.
   
  
positive.code: the instance population. The number of instances loaded and processed by the
  Python based RSL interpreter (`pyrsl`) is orders of magnitude less than before.
  
  The factored out portion was dubbed the "escher" project and produces and
  executable application called "mcmc". Escher is itself compiled with MC-3020 and
  compiled to a binary executable for each platform to which BridgePoint is
  targeted. This was done because MC-3020 is by far the most feature complete
  model compiler freely available and it was convenient to do so, but there are
  several problems with the project that require handwritten code and special
  modifications to get it to run. MC-3020 was designed for small, fast embedded
  applications -- not string processing.
  
negative.code: 
  In the translation extensions model, R2066 between TE_INSTANCE, TE_SET, and
  TE_EXTENT is not formalized and these classes do not have identifiers. ciera
  cannot handle this case. The MC-3020 loader does not have a problem with this,
  because these instances are never loaded. ciera should implement a mechanism for
  partial loading corresponding to the partial dumping described in  <<4.3.2
  Partial dumping>>. <<dr-3>>
  