Projects/frostbyte-39: Difference between revisions

Revision as of 01:24, 24 October 2007

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

@@ Line 3: / Line 3: @@
 * 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.
+** 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),
+** 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
+** All accesses to temporaries, locals should be simple offsets
-  * Can compute stack size need easily: just have a
+** 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?
+** Keep track of stack pointer?
-    * Pro: less ++ / --
+*** Pro: less ++ / --
-    * Con: garbage can linger
+*** Con: garbage can linger
-  * Basic compilation interface for evaluate:
+** Basic compilation interface for evaluate:
           void evaluateTo(CompileState* comp, ByteCodeTemp& dest);
-  * A simple peephole optimization on reads for this:
+** A simple peephole optimization on reads for this:
           t1 = local;
           t2 = t1 * t3;