Projects/frostbyte-39

From KDE TechBase
Revision as of 01:24, 24 October 2007 by SadEagle (talk | contribs)

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