[Coco] BASIC: order of operations query, and PRINT MEM

[William Astle]

On 2022-07-08 09:13, Allen Huffman via Coco wrote:
> I just started digging in to this, looking at BOTSTK which is used for the ?OM ERROR. It takes the current stack pointer, and adds BOTSTK to it.
> 
> It says BOTSTK is 58 bytes. I am looking through Unraveled to see how this stack is used. It appears to be located in upper memory before string space. In my test program, BOTSTK is 32573 and string storage starts at 32566 - which is your "about 30 bytes less."
> 
> If that’s the case, then FRETOP (start of string storage) - BOTSTK (bottom of stack at last check) would be the actual memory available.

Actually, currently available memory would be approximately the 
difference between BOTSTK and ARYEND less the STKBUF amount. MEM 
neglects to add the STKBUF adjustment in when it calculates the 
difference. Total usable memory under current PMODE/FILES/CLEAR settings 
would be the difference between BOTSTK and TXTTAB.

Note that the stack (and consequently the BOTSTK value) will grow 
downward from FOR loops, GOSUB, and expression evaluation. Expression 
evaluation can use a surprising amount of stack space depending on how 
many times it has to save state to evaluate a higher precedence 
operation, how many function calls are present, etc.

ARYEND is the top of all the memory used by the program itself, PMODE 
graphics pages, disk buffers and file descriptors, scalar variables, and 
arrays.

When calculating OM errors, it takes ARYEND, adds the amount of memory 
requested, adds the STKBUF amount, and then compares that with the 
current stack pointer. It does the comparison by storing S since you 
can't directly compare two registers.

STKBUF is 58 for whatever reason. That's sufficient to allow for a full 
interrupt frame (12 bytes) plus a buffer so routines can use the stack 
for saving registers, routine calls, etc., within reason, without having 
to continually do OM checks. It does this to prevent corrupting 
variables when memory is tight. Even so, there may be a few routines in 
Disk Basic that may still cause the stack to overflow into variable 
space when memory is very tight.