why:
step towards breaking circular dependency
details:
some functions from v2computation.nim have been extracted into
compu_helper.nim which does not explicitly back-import
v2computation.nim. all non recursive op handlers now import this source
file rather than v2computation.nim.
recursive call/create op handler still need to import v2computation.nim.
the executeOpcodes() function from interpreter_dispatch.nim has been
moved to v2computation.nim which allows for <import> rather than
<include> the interpreter_dispatch.nim source.
why:
this allows for passing back information which can eventually be
used for reducing use of exceptions
caveat:
call/create currently needs to un-capture the call-by-reference
(wrapper) argument using the Computation reference inside
why:
the previous approach was replacing the function-lets in
opcode_impl.nim by the particulate table handlers. the test
functions will verify the the handler functions are sort of
correct but not the assignments in the fork tables.
the handler names of old and new for tables are checked here.
caveat:
verifying tables currently takes a while at compile time.
details:
the op handler table is accessible via op_handlers.nim module
op handler function implementations are found in the op_handlers/
sub-directory
kludge:
for development and pre-testing, any new module can be individually
compiled setting the kludge flag using -d:kludge:1. this causes some
proc/func replacements in turn allowing for omitting imports that would
otherwise cause a circular dependency. otherwise individual compilation
would fail.
in order to prove the overall correctness of the code, the
op_handlers.nim is imported by opcodes_impl.nim when compiling all,
nimbus or test.
Jordan Hrycaj