VM - Jump table

[shargon]

Close #2987

[cschuchardt88]

But #3120 (comment) is an issue.....

[shargon]

@superboyiii could you check if something change in storage please?

[roman-khimov]

IIUC this lays the foundation for switching opcode sets/implementations of them. In a compatible way that leaves the current logic as is by default. Do I understand correctly that in future we'll choose these tables based on hardforks?

[roman-khimov]

Changes to the current logic better be in separate PRs.

[Jim8y]

@superboyiii is still in spring festival break, wont back to work until a few days later.

[shargon]

IIUC this lays the foundation for switching opcode sets/implementations of them. In a compatible way that leaves the current logic as is by default. Do I understand correctly that in future we'll choose these tables based on hardforks?

It must be exactly the same, only allow in ApplicationEngine to change the opcodes logic according to a fork.

[cschuchardt88]

IIUC this lays the foundation for switching opcode sets/implementations of them. In a compatible way that leaves the current logic as is by default. Do I understand correctly that in future we'll choose these tables based on hardforks?

It must be exactly the same, only allow in ApplicationEngine to change the opcodes logic according to a fork.

Why not have a native contract store the opcodes, so the users can have access as well? So it lives on chain.

[Jim8y]

IIUC this lays the foundation for switching opcode sets/implementations of them. In a compatible way that leaves the current logic as is by default. Do I understand correctly that in future we'll choose these tables based on hardforks?

It must be exactly the same, only allow in ApplicationEngine to change the opcodes logic according to a fork.

Why not have a native contract store the opcodes, so the users can have access as well? So it lives on chain.

Structure problem, opcode is part of the vm while vm has no reference to neo.

[cschuchardt88]

IIUC this lays the foundation for switching opcode sets/implementations of them. In a compatible way that leaves the current logic as is by default. Do I understand correctly that in future we'll choose these tables based on hardforks?

It must be exactly the same, only allow in ApplicationEngine to change the opcodes logic according to a fork.

Why not have a native contract store the opcodes, so the users can have access as well? So it lives on chain.

Structure problem, opcode is part of the vm while vm has no reference to neo.

ApplicationEngine does. Why can't we add something like ExecutionEngine.GetPrice(Opcode.PUSHT); for smart contracts.

[shargon]

IIUC this lays the foundation for switching opcode sets/implementations of them. In a compatible way that leaves the current logic as is by default. Do I understand correctly that in future we'll choose these tables based on hardforks?

It must be exactly the same, only allow in ApplicationEngine to change the opcodes logic according to a fork.

Why not have a native contract store the opcodes, so the users can have access as well? So it lives on chain.

Structure problem, opcode is part of the vm while vm has no reference to neo.

ApplicationEngine does. Why can't we add something like ExecutionEngine.GetPrice(Opcode.PUSHT); for smart contracts.

Please create a issue for this, what's the use case?

[cschuchardt88]

IIUC this lays the foundation for switching opcode sets/implementations of them. In a compatible way that leaves the current logic as is by default. Do I understand correctly that in future we'll choose these tables based on hardforks?

It must be exactly the same, only allow in ApplicationEngine to change the opcodes logic according to a fork.

Why not have a native contract store the opcodes, so the users can have access as well? So it lives on chain.

Structure problem, opcode is part of the vm while vm has no reference to neo.

ApplicationEngine does. Why can't we add something like ExecutionEngine.GetPrice(Opcode.PUSHT); for smart contracts.

Please create a issue for this, what's the use case?

Ok, Just a thought, Why make it hard to find this information? Issue will be created..

[superboyiii]

@shargon Tested, it's compatible!

[vncoelho]

Very good change!

[shargon]

I want to check the coverage before merge