status-im
/
nimbus-eth1
mirror of https://github.com/status-im/nimbus-eth1.git
2
0
Fork 0
Code Issues Projects Releases Wiki Activity
nimbus-eth1/nimbus/vm2/interpreter/op_handlers.nim

149 lines
5.1 KiB
Nim
Raw Normal View History

experimental op handlers table (tbc.) 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.
2021-04-12 17:13:30 +00:00
# Nimbus
# Copyright (c) 2018 Status Research & Development GmbH
# Licensed under either of
# * Apache License, version 2.0, ([LICENSE-APACHE](LICENSE-APACHE) or
# http://www.apache.org/licenses/LICENSE-2.0)
# * MIT license ([LICENSE-MIT](LICENSE-MIT) or
# http://opensource.org/licenses/MIT)
# at your option. This file may not be copied, modified, or distributed except
# according to those terms.
## EVM Opcode Handler Tables
## =========================
##
const
noisy {.intdefine.}: int = 0
removed kludge and simplified sources oph_call.nim and oph_create.nim why: kludge not needed anymore for oph_handlers.nim sub-sources and sources that rely on oph_handlers.nim (but not state_transactions.nim which relies on computation.nim.)
2021-04-23 17:43:44 +00:00
# isNoisy {.used.} = noisy > 0
isChatty {.used.} = noisy > 1
clean up cyclic-import-breaker function stubs where possible for op handlers why: using function stubs made it possible to check the syntax of an op handler source file by compiling this very file. this was previously impossible due cyclic import/include mechanism. details: only oph_call.nim, oph_create.nim and subsequently op_handlers.nim still need the -d:kludge:1 flag for syntax check compiling. this flag also works with interpreter_dispatch.nim which imports op_handlers.nim.
2021-04-21 17:04:54 +00:00
experimental op handlers table (tbc.) 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.
2021-04-12 17:13:30 +00:00
import
integrated current op handlers into opcodes_impl.nim (tbc.) why: integration tests will verify op code handlers which wher rephrased from the very opcodes_impl module into the handler tables.
2021-04-13 16:23:39 +00:00
strformat,
clean up cyclic-import-breaker function stubs where possible for op handlers why: using function stubs made it possible to check the syntax of an op handler source file by compiling this very file. this was previously impossible due cyclic import/include mechanism. details: only oph_call.nim, oph_create.nim and subsequently op_handlers.nim still need the -d:kludge:1 flag for syntax check compiling. this flag also works with interpreter_dispatch.nim which imports op_handlers.nim.
2021-04-21 17:04:54 +00:00
./forks_list,
experimental op handlers table (tbc.) 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.
2021-04-12 17:13:30 +00:00
./op_codes,
./op_handlers/[oph_defs,
re-integrated 0x4# op handlers
2021-04-14 10:40:55 +00:00
oph_arithmetic, oph_hash, oph_envinfo, oph_blockdata,
re-integrated 0x60..0xaf (push, dup, swap, log) op handlers
2021-04-15 13:40:31 +00:00
oph_memory, oph_push, oph_dup, oph_swap, oph_log,
re-integrated call op handlers
2021-04-16 15:06:02 +00:00
oph_create, oph_call, oph_sysops]
experimental op handlers table (tbc.) 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.
2021-04-12 17:13:30 +00:00
clean up cyclic-import-breaker function stubs where possible for op handlers why: using function stubs made it possible to check the syntax of an op handler source file by compiling this very file. this was previously impossible due cyclic import/include mechanism. details: only oph_call.nim, oph_create.nim and subsequently op_handlers.nim still need the -d:kludge:1 flag for syntax check compiling. this flag also works with interpreter_dispatch.nim which imports op_handlers.nim.
2021-04-21 17:04:54 +00:00
const
allHandlersList = @[
(vm2OpExecArithmetic, "Arithmetic"),
(vm2OpExecHash, "Hash"),
(vm2OpExecEnvInfo, "EnvInfo"),
(vm2OpExecBlockData, "BlockData"),
(vm2OpExecMemory, "Memory"),
(vm2OpExecPush, "Push"),
(vm2OpExecDup, "Dup"),
(vm2OpExecSwap, "Swap"),
(vm2OpExecLog, "Log"),
removed kludge and simplified sources oph_call.nim and oph_create.nim why: kludge not needed anymore for oph_handlers.nim sub-sources and sources that rely on oph_handlers.nim (but not state_transactions.nim which relies on computation.nim.)
2021-04-23 17:43:44 +00:00
(vm2OpExecCreate, "Create"),
(vm2OpExecCall, "Call"),
clean up cyclic-import-breaker function stubs where possible for op handlers why: using function stubs made it possible to check the syntax of an op handler source file by compiling this very file. this was previously impossible due cyclic import/include mechanism. details: only oph_call.nim, oph_create.nim and subsequently op_handlers.nim still need the -d:kludge:1 flag for syntax check compiling. this flag also works with interpreter_dispatch.nim which imports op_handlers.nim.
2021-04-21 17:04:54 +00:00
(vm2OpExecSysOp, "SysOp")]
experimental op handlers table (tbc.) 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.
2021-04-12 17:13:30 +00:00
# ------------------------------------------------------------------------------
# Helper
# ------------------------------------------------------------------------------
clean up cyclic-import-breaker function stubs where possible for op handlers why: using function stubs made it possible to check the syntax of an op handler source file by compiling this very file. this was previously impossible due cyclic import/include mechanism. details: only oph_call.nim, oph_create.nim and subsequently op_handlers.nim still need the -d:kludge:1 flag for syntax check compiling. this flag also works with interpreter_dispatch.nim which imports op_handlers.nim.
2021-04-21 17:04:54 +00:00
proc mkOpTable(selected: Fork): array[Op,Vm2OpExec] {.compileTime.} =
# Collect selected <fork> entries
for (subList,subName) in allHandlersList:
for w in subList:
if selected notin w.forks:
continue
# definitions must be mutually exclusive
var prvInfo = result[w.opCode].info
if prvInfo != "" or 0 < result[w.opCode].forks.card:
echo &"*** {subName}: duplicate <{w.opCode}> entry: ",
&"\"{prvInfo}\" vs. \"{w.info}\""
doAssert result[w.opCode].info == ""
doAssert result[w.opCode].forks.card == 0
result[w.opCode] = w
re-integrated 0x5# op handlers
2021-04-14 16:34:24 +00:00
clean up cyclic-import-breaker function stubs where possible for op handlers why: using function stubs made it possible to check the syntax of an op handler source file by compiling this very file. this was previously impossible due cyclic import/include mechanism. details: only oph_call.nim, oph_create.nim and subsequently op_handlers.nim still need the -d:kludge:1 flag for syntax check compiling. this flag also works with interpreter_dispatch.nim which imports op_handlers.nim.
2021-04-21 17:04:54 +00:00
# Initialise unused entries
experimental op handlers table (tbc.) 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.
2021-04-12 17:13:30 +00:00
for op in Op:
clean up cyclic-import-breaker function stubs where possible for op handlers why: using function stubs made it possible to check the syntax of an op handler source file by compiling this very file. this was previously impossible due cyclic import/include mechanism. details: only oph_call.nim, oph_create.nim and subsequently op_handlers.nim still need the -d:kludge:1 flag for syntax check compiling. this flag also works with interpreter_dispatch.nim which imports op_handlers.nim.
2021-04-21 17:04:54 +00:00
if selected notin result[op].forks:
re-integrated 0x5# op handlers
2021-04-14 16:34:24 +00:00
result[op] = result[Invalid]
result[op].opCode = op
verifying new op handler tables layout against original tables 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.
2021-04-19 09:15:35 +00:00
if op == Stop:
result[op].name = "toBeReplacedByBreak"
experimental op handlers table (tbc.) 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.
2021-04-12 17:13:30 +00:00
# ------------------------------------------------------------------------------
simplify interpreter_dispatch.nim code details: replace generated macro loop/switch by explicit call using the fork/op handler matrix (encapsulated via opHandlersRun() function)
2021-04-20 11:14:43 +00:00
# Public functions
experimental op handlers table (tbc.) 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.
2021-04-12 17:13:30 +00:00
# ------------------------------------------------------------------------------
remove obsolete files why: opcodes_impl.nim was fully replaced by functionality from op_handlers.nim
2021-04-20 11:22:48 +00:00
#const
# vm2OpHandlers* = block:
# var rc: array[Fork, array[Op, Vm2OpExec]]
# for w in Fork:
# rc[w] = w.mkOpTable
# rc
experimental op handlers table (tbc.) 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.
2021-04-12 17:13:30 +00:00
simplify interpreter_dispatch.nim code details: replace generated macro loop/switch by explicit call using the fork/op handler matrix (encapsulated via opHandlersRun() function)
2021-04-20 11:14:43 +00:00
type
re-implemented handler-call statement by doubly nested case statement why: the new implementation lost more then 25% execution time on the test suite when compared to the original VM. so the handler call and the surrounding statements have been wrapped in a big case statement similar to the original VM implementation. on Linux/x64, the execution time of the new VM2 seems to be on par with the old VM. details: on Linux/x64, computed goto works and is activated with the -d:release flag. here the execution time of the new VM2 was tested short of 0.02% better than the old VM. without the computed goto, it is short of 0.4% slower than the old VM.
2021-04-22 11:02:13 +00:00
vmOpHandlersRec* = tuple
name: string ## Name (or ID) of op handler
info: string ## Some op handler info
run: Vm2OpFn ## Executable handler
re-integrated 0x60..0xaf (push, dup, swap, log) op handlers
2021-04-15 13:40:31 +00:00
simplify interpreter_dispatch.nim code details: replace generated macro loop/switch by explicit call using the fork/op handler matrix (encapsulated via opHandlersRun() function)
2021-04-20 11:14:43 +00:00
const
# Pack handler record.
#
# Important:
# As of NIM 1.2.10, this mapping to another record is crucial for
#
# vmOpHandlers[fork][op].run
#
# to pick right function when <op> is a variable . Using
#
# vm2OpHandlers[fork][op].exec.run
#
# only works when <op> is a constant. There seems to be some optimisation
# that garbles the <exec> sub-structures elements <prep>, <run>, and <post>.
# Moreover, <post> is seen NULL under the debugger. It is untested yet
# under what circumstances the vm2OpHandlers[] matrix is set up correctly.
# Linearising/flattening the index has no effect here.
#
re-implemented handler-call statement by doubly nested case statement why: the new implementation lost more then 25% execution time on the test suite when compared to the original VM. so the handler call and the surrounding statements have been wrapped in a big case statement similar to the original VM implementation. on Linux/x64, the execution time of the new VM2 seems to be on par with the old VM. details: on Linux/x64, computed goto works and is activated with the -d:release flag. here the execution time of the new VM2 was tested short of 0.02% better than the old VM. without the computed goto, it is short of 0.4% slower than the old VM.
2021-04-22 11:02:13 +00:00
vmOpHandlers* = ## Op handler records matrix indexed `fork` x `op`
block:
var rc: array[Fork, array[Op, vmOpHandlersRec]]
for fork in Fork:
var tab = fork.mkOpTable
for op in Op:
rc[fork][op].name = tab[op].name
rc[fork][op].info = tab[op].info
rc[fork][op].run = tab[op].exec.run
rc
re-integrated 0x5# op handlers
2021-04-14 16:34:24 +00:00
simplify interpreter_dispatch.nim code details: replace generated macro loop/switch by explicit call using the fork/op handler matrix (encapsulated via opHandlersRun() function)
2021-04-20 11:14:43 +00:00
# ------------------------------------------------------------------------------
# Debugging ...
# ------------------------------------------------------------------------------
re-integrated 0x5# op handlers
2021-04-14 16:34:24 +00:00
removed kludge and simplified sources oph_call.nim and oph_create.nim why: kludge not needed anymore for oph_handlers.nim sub-sources and sources that rely on oph_handlers.nim (but not state_transactions.nim which relies on computation.nim.)
2021-04-23 17:43:44 +00:00
when isMainModule and isChatty:
re-implemented handler-call statement by doubly nested case statement why: the new implementation lost more then 25% execution time on the test suite when compared to the original VM. so the handler call and the surrounding statements have been wrapped in a big case statement similar to the original VM implementation. on Linux/x64, the execution time of the new VM2 seems to be on par with the old VM. details: on Linux/x64, computed goto works and is activated with the -d:release flag. here the execution time of the new VM2 was tested short of 0.02% better than the old VM. without the computed goto, it is short of 0.4% slower than the old VM.
2021-04-22 11:02:13 +00:00
proc opHandlersRun(fork: Fork; op: Op; d: var Vm2Ctx) {.used.} =
## Given a particular `fork` and an `op`-code, run the associated handler
vmOpHandlers[fork][op].run(d)
proc opHandlersName(fork: Fork; op: Op): string {.used.} =
## Get name (or ID) of op handler
vmOpHandlers[fork][op].name
proc opHandlersInfo(fork: Fork; op: Op): string {.used.} =
## Get some op handler info
vmOpHandlers[fork][op].info
simplify interpreter_dispatch.nim code details: replace generated macro loop/switch by explicit call using the fork/op handler matrix (encapsulated via opHandlersRun() function)
2021-04-20 11:14:43 +00:00
echo ">>> berlin[shl]: ", FkBerlin.opHandlersInfo(Shl)
echo ">>> berlin[push32]: ", FkBerlin.opHandlersInfo(Push32)
echo ">>> berlin[dup16]: ", FkBerlin.opHandlersInfo(Dup16)
echo ">>> berlin[swap16]: ", FkBerlin.opHandlersInfo(Swap16)
echo ">>> berlin[log4]: ", FkBerlin.opHandlersInfo(Log4)
echo ">>> frontier[sstore]: ", FkFrontier.opHandlersInfo(Sstore)
echo ">>> constantinople[sstore]: ", FkConstantinople.opHandlersInfo(Sstore)
echo ">>> berlin[sstore]: ", FkBerlin.opHandlersInfo(Sstore)
experimental op handlers table (tbc.) 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.
2021-04-12 17:13:30 +00:00
# ------------------------------------------------------------------------------
# End
# ------------------------------------------------------------------------------