Stack implementation in a VM

Started by
-1 comments, last by umbrae 18 years, 4 months ago
I want to use just one stack for the vm, is this a good idea? local variables and parameters etc are on this stack. There is nowhere else to store stuff. (Apart from class properties etc.) I also would like each method to have a 'base' stack offset that's automatically remembered (will help with my closure type things). Methods need to access parameters given to them, and pop them off when they are finished and optionally push a return value. Options Have a "I'm going to place parameters on the stack now so remember this location" opcode so the called method accesses from that offset
  • too complicated if you want to keep something on the stack and call another method with it
  • method calling is more complicated... requires two opcodes
  • messy
Part of calling a method is to supply the number of the parameters on the stack (this value is subtracted off the current stack offset and that's the called method's offset.
  • extra opcode, or one opcode but the next 'chunk' of code is the method offset
  • method calling is more complicated... requires two opcodes
  • Fairly elegant solution
Methods can access parts of the stack below their 'start' using extra opcodes (negative indices)
  • extra opcode
  • breaks down a bit when popping off the parameters to place the return value
  • not very cool solution
Stack offset is reverse (the top item on the stack is 0 in opcode terminology)
  • uses existing opcodes
  • complier has to change offsets for variables each time we push
  • Fairly elegant solution for the vm, ugly for the compiler
Another solution is to have some form of local variables that are on a separate stack, or somewhere else in memory. I'd rather not use this because it compilcates things. Thoughts? Suggestions? Something I've missed? At the moment I'm leaning towards the 2nd option.

This topic is closed to new replies.

Advertisement