Feature or Enhancement?
- ( ) New feature
- (x) Enhancement of existing feature
Description
Currently, ops like ADD_INTS require their count argument be the next byte in the tape rather than the top value of the stack. This means that calculating the sum of an arbitrary number of integers, where the count is not known ahead of time, requires reducing the stack with a loop. This is highly inefficient compared to pulling the count argument from the stack.
The ops that need this change are the following:
It is likely that the following will also benefit from this change, but these might need to be put into a separate issue for a later release after further analysis:
Additional context
This will be a hard-fork breaking change and require a lot of work, but it will greatly reduce the computational complexity and script length for these use cases. The simpler use case originally envisioned is not coming up in real use nearly as often as this more complicated use case.
An alternate method would be to add _STACK variants using op code values 92+ (starting at 0x5c). However, the additional complexity from doing so is unlikely to be a benefit in the future. The experience thus far has been that an argument on the stack is almost universally better than an argument as the next byte on the tape, with the narrow exception of signature checking ops.
Feature or Enhancement?
Description
Currently, ops like
ADD_INTSrequire theircountargument be the next byte in the tape rather than the top value of the stack. This means that calculating the sum of an arbitrary number of integers, where the count is not known ahead of time, requires reducing the stack with a loop. This is highly inefficient compared to pulling the count argument from the stack.The ops that need this change are the following:
OP_ADD_INTSOP_SUBTRACT_INTSOP_MULT_INTSOP_ADD_FLOATSOP_SUBTRACT_FLOATSIt is likely that the following will also benefit from this change, but these might need to be put into a separate issue for a later release after further analysis:
OP_ADD_POINTSOP_ADD_SCALARSOP_SUBTRACT_SCALARSOP_SUBTRACT_POINTSAdditional context
This will be a hard-fork breaking change and require a lot of work, but it will greatly reduce the computational complexity and script length for these use cases. The simpler use case originally envisioned is not coming up in real use nearly as often as this more complicated use case.
An alternate method would be to add
_STACKvariants using op code values 92+ (starting at 0x5c). However, the additional complexity from doing so is unlikely to be a benefit in the future. The experience thus far has been that an argument on the stack is almost universally better than an argument as the next byte on the tape, with the narrow exception of signature checking ops.