Skip to content
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

Inconsistent handling of stack-underflow #107

Open
MaxBarraclough opened this issue Dec 19, 2021 · 2 comments
Open

Inconsistent handling of stack-underflow #107

MaxBarraclough opened this issue Dec 19, 2021 · 2 comments

Comments

@MaxBarraclough
Copy link
Contributor

Different words handle stack-underflows differently. There is inconsistency between words, and also inconsistency within certain words, in that some words throw on some but not all underflow conditions.

A few examples:

  • . detects when the stack is empty and throws
  • The basic binary arithmetic words (+, -, *, /) throw if the stack is empty, but fail to throw when there's 1 value on the stack. The result of running one of these words when 1 value is on the stack, is an empty stack.
  • CELLS does not throw when the stack is empty (results in an empty stack)
  • DUP and 2DUP do not detect when the stack is empty, and push garbage values in that circumstance
  • SWAP does not detect if the stack is empty. If run when there is 1 value on the stack, the result is that the stack holds 1 value (of garbage).
  • 2SWAP does something similar to SWAP
@philburk
Copy link
Owner

In most of these cases, it was considered too costly to do the stack checking on these words. Words like + and * are meant to be optimized. The . prints so adding a stack check there was not too expensive.

When running the outer interpreter, I check at the end of the line. But not in the middle. I could add that.

2 3 drop drop   / no error
2 drop drop 3  / does not throw error but should because of temporary underflow

@MaxBarraclough - Would it help to add a compiler flag so that the primitives in pf_inner.c did underflow checking?
I could put some checks in the M_POP() and M_DROP() macros.

@MaxBarraclough
Copy link
Contributor Author

@MaxBarraclough - Would it help to add a compiler flag so that the primitives in pf_inner.c did underflow checking? I could put some checks in the M_POP() and M_DROP() macros.

That sounds like a great solution. Are you thinking of 2 options (something like CHECKED/UNCHECKED) or 3 options (something like FULLY_CHECKED/PARTIALLY_CHECKED/UNCHECKED)?

If the performance penalty of full checking is significant, it might make good sense to default to partial checking, with the option of no checks at all for people looking for maximum performance.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants