-
Notifications
You must be signed in to change notification settings - Fork 1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Suggestion for adding OpCode PUSH1BYTE and DUP3RD #3530
Comments
I'm good with it, it will make cheaper the executions, it's good for all |
If we decide this, maybe we can also have some V2 opcodes, for instance, POPITEM, APPEND, to avoid DUP, but directly peek the item and update the stackitem value. |
Can be done, but not a priority to me, it's just an optimization and pretty minor one. It's not that we can't do something without some of these opcodes. And it needs to be evaluated against real contracts, different compilers, quite some work there. |
v3.9 is already not priority, next big version is v3.8. can be removed when we really have to decide v3.9, otherwise this issue will be lost forever, and no one really care about it anymore. |
no plan for 3.9 yet, wont hurt anyone to mark it so that we can pick it up later. |
Well, can be added to project as well. |
For me is something that doesn't hurt anyone, it only improves, and we can add it without problems with the jumpTable now. |
Summary or problem description
For now we push 1 byte of data (typically for storage prefix) with PUSHDATA1 (priced 1<<3 GAS😰), which also has to include the length of data. This is a waste of time, storage and GAS.
Also, for operations involving 3 elements, we are always having trouble copying the 3rd element to the top of stack.
Do you have any solution you want to propose?
Add PUSH1BYTE = 0x06 that pushes 1 byte of ByteString to top of evaluation stack, at a GAS price of no more than LDLOC (1<<1), or preferrably 1<<0. This is for pushing 1-byte prefixes, often used in storage.
Add DUP3RD = 0x4C that copies the 3rd (with index 2) item to top of evaluation stack, at the same price of DUP and OVER (1<<1). This is for the convenience of operating 3 elements.
Of course they are just temporary names and byte assignments, and I am not in any hurry for any change to be made. My estimate is that, the marginal yield of PUSH1BYTE can be much higher than DUP3RD and many of the existing instructions. Maybe we can consider to include it after the next major release.
Where in the software does this update applies to?
The text was updated successfully, but these errors were encountered: