Projects/frostbyte-39: Difference between revisions
< Projects
(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...) |
(No difference)
|
Revision as of 01:22, 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