add price for ASSERTMSG and ABORTMSG opcodes

[ixje]

to support neo-project/neo-vm#491

[shargon]

It should be the same as POP

[ixje]

@shargon that price sounds a bit excessive if we're going to give it a price other than the regular ABORT, ASSERT anyway.

ABORTMSG has just 1 Pop() in its implementation, all JMPIF* instructions have 1 POP and a lot more logic in the ExecuteJump() function and those only cost 1 << 1.

Similar, ASSERTMSG has 2 POPs, like all of the jump instructions with a comparison (JMPEQ, JMPNE, JMPGT etc), they also all cost 1 << 1.

This price is basically the equivalent of INITSLOT which has a for-loop pop'ing n items and what not. Even all arithmetic operators cost less at 1 << 3.

[roman-khimov]

@shargon, we have 0 for RET for a long long time. RET does some processing that can cost more than POP and there can be 1024 RETs invoked in a row without any cost. Then in #1875 (comment) ABORT was set to 0 as well because it's always the last instruction to perform. ASSERT was defined to be 0 as well in c6c009a of #2045, even though technically it already pops something off the stack. But it also is the last instruction to execute, so it can be free.

Now ABORTMSG is the same computationally as the old ASSERT, so it should be 0. And ASSERTMSG should just follow the suite, an additional POP is negligible and it's also the last thing to execute.

[ixje]

@shargon ☝️

[Jim8y]

@shargon ☝️

[shargon]

@shargon, we have 0 for RET for a long long time. RET does some processing that can cost more than POP and there can be 1024 RETs invoked in a row without any cost. Then in #1875 (comment) ABORT was set to 0 as well because it's always the last instruction to perform. ASSERT was defined to be 0 as well in c6c009a of #2045, even though technically it already pops something off the stack. But it also is the last instruction to execute, so it can be free.

Now ABORTMSG is the same computationally as the old ASSERT, so it should be 0. And ASSERTMSG should just follow the suite, an additional POP is negligible and it's also the last thing to execute.

we must learn from the mistakes of the past, I think that if there are pop operations internally, the minimum should have that cost plus another, otherwise the cost is miscalculated, however, I see that the only one who disagrees is me so I will accept the decision 😊

[shargon]

It seems that the nuget package doesn't work :S

[ixje]

It seems that the nuget package doesn't work :S

You can see it was working when I did my initial PR. Perhaps it gets auto deleted after some time?

[roman-khimov]

the minimum should have that cost plus another, otherwise the cost is miscalculated

Yeah, that was my thinking in #1875, but I can find another argument for zero-cost ASSERT and alike. Suppose you're executing a script and there is 0.00000001 GAS left for its execution. The next instruction is some ASSERT/ABORTMSG/ASSERTMSG. If they're to have some cost, you'd get "out of GAS" exception, but when they cost zero you get whatever is appropriate for the instruction. I think in most cases you'd prefer getting ASSERT/ABORT message.

[shargon]

It seems that the nuget package doesn't work :S

You can see it was working when I did my initial PR. Perhaps it gets auto deleted after some time?

I know, but it doesn't work also in my local...

[ixje]

It seems that the nuget package doesn't work :S

You can see it was working when I did my initial PR. Perhaps it gets auto deleted after some time?

I know, but it doesn't work also in my local...

If the package had something like a 7-day retention then of course it will also not work locally as it has long expired by now. I guess you have to ask @erikzhang as he's the one that has setup that myget publishing so he should be able to see what happend to the package on the myget website. Or you can perhaps rerun the workflow to have it publish again (just for the sake of your testing)

[shargon]

Or you can perhaps rerun the workflow to have it publish again (just for the sake of your testing)

Done