The interpreter depends on the various ops files for actually executing byte code.
Currently all ops files except obscure.ops get logically appended and built into core_ops_*.c. This makes for huge core_ops files, with a lot of unused operations, bad cache locality and so on. It will get worse, when different HLs have more needs for special ops like dotgnu.ops, we now already have.

So here is a scheme that allows for a small core.ops, easy extension and no execution speed penalty for non core ops.

1) core.ops is really core (ev. minus the trigonometric ops, which could go into math.ops)

2) There is one additional opcode

oplib "opsname" # e.g. opsfile "math"

3) Additional opsfiles are either compiled statically into the interpreter, or get loaded dynamically via Parrot_{dlopen, dlsym}

4) Above B<oplib> opcodes have to appear in the assembler (i.e. imcc) in the same order as during runtime, simplest, just put them at the beginning.

5) When imcc encounters such a B<oplib>, imcc loads the op_info of the opsfile and appends it to the cores op_info

6) imcc thus spits out consecutive opcode numbers, like if these opsfiles were appended to core.ops in the order they are seen.

7) During runtime the op_func_tables get appended to core.ops' op_func_table and all loaded oplibs get a pointer to this common op_func_table. So due to 4) there again is a op_jump_table entry for the opcode number.

That's it, modulo some additions for prederef and JIT, compiled C would need more work.

I wrote a test program, showing what's on using the CGoto core:

core.ops (5 ops) : end, noop, oplib, "op 3", "op 4"
math.ops (2 ops): add5, sub5 (internally 0 and 1, real 5 and 6)
math2.ops (2 ops) : mul5, div5 (=> 7 and 8)

Here is a test run of:
opcode_t prog3[] = {3,20, 4,21, 2,0, 2,1, 5,10, 7,10, 3,30, 8,20, 0};

op 3: 20
op 4: 21
oplib: math
*** found static lib 'math'
oplib: math2
*** found dynamic lib 'math2'
add5 5+10=15
mul5 5*10=50
op 3: 30
div5 20/5=4
end

The "2, 0" and "2, 1" ops are oplib "math" (statically linked) and oplib "math2" (dynamically linked), the 0/1 operands point into the constant_table.

Appended is the test program, systems without dlopen/dlsym would need some work like in platform.c.

Have fun,
leo

Attachment: ext_oplib.tgz
Description: GNU Unix tar archive

Reply via email to