But that's not a hasg table. That's a weird thing: an array + linked list.

What I guess you want is a hash table where the indexing key is a pair {opcode, num_args}.

Some base code:

Another, easier, options is go with c++ and use a map.

I usually add a void * to point to the callback function. The callback is like typedef int (*callback_fn)(void *, void *). The first pointer gets the input and the second the output if any. When calling a function, I set the data in the first pointer (or fill a struct if the function needs more information). Lately I have been using a void *stack_fn[D_STACKSIZE];. Whenever I call a function, I push values into the stack, and pass it as first parameter. The function knows what to do with the stack. That is one of the best ways I worked with.

The struct would look like:

And so on. Note that this is an example, and might not compile. Nor I am checking if the stack has NULL values in it. Since the array is sorted, I use qsort to look for the opcode (if there are gaps between opcodes) or just direct access if they are ordered.

To generate things in compile time, I use a file like:

[ OPCODE ]
NUMBER      := 0x00
NAME        := NOP
ARGUMENTS   := 0

[ CODE ]
/*  takes one cycle of script time  */
int nop(void *in, void *out) {
    cycle_count++;

    return (D_SUCCESS);
}

A perl script parses all the files (one file for all, or one file per opcode) and generates the header and source file. I used this with a card generator in a trading card game (I file per card) and worked nicely.

RB: My opcode defn files look something like:

op ADD (int in, int in, int out) {
   $3 = $1 + $2;
}

op ADD (int in, int inout) {
   $2 += $1;
}

op ADD (int in, int in, value out) {
   $3->vtable->assign_int( $1 + $2 );
}

op ADD (value in, value inout) {
   $2->vtable->add_value($1);
}

And the core defns... I'm not sure how they'll look at the moment, but they need to beable to define the exececution core, which can be a function with a loop+switch configuration, a cgoto config, or maybe a loop+functable config. The cgoto core will always be the fastest, but is only doable on GCC, so I Want to provide other cores for other compilers (ie: MSVC) that don't support "computed goto"s.

Thats a possibility. I was only using the hash layout because I already have hashing code I dunno.

edit:

heres sorta what the exec cgoto core "may" look like:

The table I am wanting to build isn't for the VM itsself, its more for the assembler to know what ops can be used, without hard codeing them

And if I did make a functable dispatch method, I'd just pass the op pointer which stores the args in a little array.