Checking for Data Stack under- and overflow on the 65816

[JimBoyd]

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: Select all

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.