Projects/frostbyte-39

From KDE TechBase
Revision as of 01:22, 24 October 2007 by SadEagle (talk | contribs) (New page: === Bytecode needs/design goals/whatever === * Initial overview: do it a function at a time. Function calls still do callAsFunction: * But can setup the arguments on the stack frame, a...)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)

Bytecode needs/design goals/whatever

  • Initial overview: do it a function at a time. Function calls still

do callAsFunction:

 * But can setup the arguments on the stack frame, along with the length. 
   List integration with that may be tricky, especially for native calls.
  • Goal #1: cheap temporaries --- make the wiring inexpensive
 * M.O.: my tendency is towards simpler bytecode (think Copy4, Copy8), 
   for simpler optimization; critical for that, nice otherwise
 * All accesses to temporaries, locals should be simple offsets
 * Can compute stack size need easily: just have a 
    ByteCodeTemp class that links in to a counter in 
    compilation context. So there is no need to put in conditionals 
    on push/pop. Also, this gives the temporaries an explicit name,
    which can be in a shared namespace with locals. Somewhat (see below)
 * Keep track of stack pointer?
   * Pro: less ++ / --
   * Con: garbage can linger
 * Basic compilation interface for evaluate:
        void evaluateTo(CompileState* comp, ByteCodeTemp& dest);
 * A simple peephole optimization on reads for this:
        t1 = local;
        t2 = t1 * t3;
   will probably be a good idea. Not sure if full copy prop is worth anything


 * Limit reallocations -- entering a context should do only a single 
   stack frame allocation


  • Literals should go into some sort of a symbol table
  • Obviously, would like globals to used all of the above
 * Problem: symbol tables, stack frames might grow. May require 
   segmenting them an multiple subst