GARTHWILSON wrote:
scotws wrote:
It's the legal (!) empty status that can be the real problem. Some words like 1+ only work if there is a non-empty stack; SWAP needs at least two entries, ROT even three. We can either accept those errors silently (which is fastest) or check in the word itself (which takes longer).
I left 8 bytes behind there so things like that wouldn't do any damage.
I only left 6 bytes.
Quote:
After all the intended execution of a word being tested, any empty-stack condition is caught by INTERPRET with ABORT" Empty stack". This is only in development, and is never needed after development is completed, and has no effect on execution speed. You could still mess it up with something like 5 ROLL but how often are you going to do that and have inadequate depth? In my 25+ years of playing with this, I've never had the problem.
I'm not that familiar with the 65816, but if the X and Y registers are in 8-bit mode then I assume that if X is greater than hexadecimal 7F, then it would be negative. If that is the case then it would be possible on an ITC Forth to implement zero overhead underflow limiting. Define
2DROP close enough to
NEXT and branch to
NEXT if X does not go negative. If a page boundary is avoided, at least on the 6502, the branch is only 3 cycles ( same as a jump ). The code does
not correct an underflow, but limits it so
?STACK or something similar in the interpreter can catch it and abort.
Code:
CODE 2DROP
INX, INX,
// DROP's CFA POINTS HERE
INX, INX,
NEXT 0< NOT BRAN, // branch to next if no underflow
80 # LDX, // limit the underflow
NEXT JMP, END-CODE
The idea is to keep an underflow from underflowing deep enough to do harm.
Edit: Forgot to mention that the
X register is the data stack pointer and when the stack is empty
X has the hexadecimal value 7E.
Login
Register
FAQ
Search
