========================================
Translatable LLInterpreter Working Group
========================================

Samuele Pedroni, Anders Chrigstrom, Anders Lehmann,
Carl Friedrich Bolz, Ludovic Aubry


Relation to JIT work
====================

 * give hints about arguments that should be considered constant
 * assembler hard to debug / not portable
 * plan is to produce low level graphs
 * (to make this faster later, we could later improve this by really producing
   machine code)


Other reasons for TLLI
======================

 * better debugging
 * enable improving the GCs


Requirements that follow from this
===================================

 * it should be translatable (evidently)
 * need to call functions written in C/other backend
 * there must be a manipulabable memory representation of the low level graphs
 * a future goal would be to be able to use the LLInterp only for parts of the
   codebase -- this relates to separation of compilation

Questions
=========

 * what to do about types? the layout has to be compatible with what the C
   compilers do
   
    - one possiblity would be to encode the types in the serialized graphs in
      a platform dependent manner
      
 * how would external function calls work?
 
    - you would probably have to have wrapper function for every signature that
      occurs
      
 * it will probably be necessary to mix hl and ll. is that possible?

Tasks
=====

 * support for addresses in the backends
 * thinking about the memory representation of the ll graphs
 * thinking about how to treat external functions
 * writing the llinterp


Advanced topics
===============

 * some parts of the information that the llinterpreter will need to interpret 
   the graphs may be messy to pass to it. so an idea would be to generate parts
   of the llinterpreter as part of the rtyping process: basically a special
   function saying "I'd like an llinterpreter for this function"