Runtime stack is the way to go. on how much memory it takes up depends on whether you use a array or a linked list for your runtime stack. an Array is fast because it is referenced by indicies, but linked lists allow the stack to be of any size. its up to you but i would go with the speed of an array and just make some sort of opcode to set the stacksize within the script. if you really think about it it doesn't *waste* to much memory... I.E.:

struct sVariable
{
char iType;
union
{
float fFloat;
char* pString;
int iInt;
}
};

the size of that struct is 5 bytes because of the union.

so a stack size of 200 would be 1000 bytes.

IMO the array is the way to go. just make sure and add good error checking for stack over flow and what not...or if you really get creative you could make your V Machine reallocate the stack in a bigger size (could just use vectors if your thinking C++)... just a thought.

hope i may have helped.

EDIT:

About the Variable tables... in your compiled code, there is no need for variable tables because any intruction (opcode) that references a "variable" is just a reference(index) to a stack. When compiling however, you must create a Identifier table.

here is a sample assembly like script function:

func myfunc:
local Var1 ; create a local variable
local Var2 ; create a 2nd local varable
mov var1, 0 ; move 0 into var1
add, var2, 2, 1 ; add 2+1 and store in var2
ret


Parsing this script with 2 passes would go something like this



FIRST PASS:
-----------

- Look for any DIRECTIVE that would define an Identifier (I.E. "local" and "func" from our about script)
- Add these Identifiers to their appropriate lookup tables

from the above script we would have 2 lookup tables:

Func Identifier Table:
myfunc

Local Identifier Table:
Var1
Var2

- Calculate things like instruction count, line count, and the Local data size of each function. (any thing that is useful to the second pass).


SECOND PASS:
------------

- Parse intructions into opcode (make sure and check for type missmatches and undefined Identifiers and all that good stuff)

from the above line "mov var1, 0"

this could be thought as:

mov StackRef[0], Literal[0]

Imagine mov's opcode is 0 and Stackref Operand Type is 0 and Literal Operand Type is 1
The bytecode (represented in numbers) would look like this:

00010

i put a type number infront of each operand value.

To figure out what the stack reference is, you take into account what the local data size is(from first pass) and sice we got 2 since there are 2 local varibles we know that our locals are stored into stack indices 0 and 1.



I hope i may have helped in any way...if i have caused any confusion please ask..

-sky.

[edited by - skyblu on October 20, 2003 1:41:46 PM]

[edited by - skyblu on October 20, 2003 1:43:36 PM]

[edited by - skyblu on October 20, 2003 1:44:24 PM]

quote: Original post by Clash
I just recently finished writing an assembler and found that, for local variables, negative indeces are the way to go. If you think of an index of -1 as being "the top of the runtime stack," then the local variable indeces will resolve correctly regardless of how deep the recursive function calls get.

yes this is the way to go...if you want to implement globals you reference memory in number >= 0 any local data is reference as < 0.

sky





my teeth are tired from chewing demon bones.