Finite stacks #19

Open
opened 2025-01-05 07:12:42 +00:00 by GlowingOutlaw · 1 comment
Collaborator

Currently our stacks have a maximum size, and the memory for each is allocated at execution start. However this limits our programs, and will eventually cause our programs to revert, which is against the overall philosophy of doing no-ops on invalid states. We have to look into ways of letting our stacks grow, either in memory with some sort of allocator, or simply by using transient storage. Implementation simplicity as well as gas cost should be considered.

Currently our stacks have a maximum size, and the memory for each is allocated at execution start. However this limits our programs, and will eventually cause our programs to revert, which is against the overall philosophy of doing no-ops on invalid states. We have to look into ways of letting our stacks grow, either in memory with some sort of allocator, or simply by using transient storage. Implementation simplicity as well as gas cost should be considered.
Owner

when stacks grow certain operations increase in gas cost (yank and shove need loop), so in general there should be fixed limits to allows us to evade tx gas limit. the docs have this for the code stack:

MAX-POINTS-IN-PROGRAM: This is the maximum size of an item on the CODE stack, expressed as a number of points. A point is an instruction, a literal, or a pair of parentheses. Any instruction that would cause this limit to be exceeded should instead act as a NOOP, leaving all stacks in the states that they were in before the execution of the instruction. 

could this be applied to all other stacks?

to disincentivise stack overflow the NOOP could be accompanied by an fitness penalty somehow.

our brains instinctively know their stack size, how?
when I fail to understand something, I know it, there is null on the stack, as before.

when stacks grow certain operations increase in gas cost (yank and shove need loop), so in general there should be fixed limits to allows us to evade tx gas limit. the docs have this for the code stack: ``` MAX-POINTS-IN-PROGRAM: This is the maximum size of an item on the CODE stack, expressed as a number of points. A point is an instruction, a literal, or a pair of parentheses. Any instruction that would cause this limit to be exceeded should instead act as a NOOP, leaving all stacks in the states that they were in before the execution of the instruction. ``` could this be applied to all other stacks? to disincentivise stack overflow the NOOP could be accompanied by an fitness penalty somehow. our brains instinctively know their stack size, how? when I fail to understand something, I know it, there is null on the stack, as before.
Sign in to join this conversation.
2 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: giteadmin/SoLUSH-3#19