The mystery of the ADR results

[vol]

I have played with a tiny program

10 DIM A$(1000)
20 PRINT ADR(a$)

After RUN I get 2091, then after PRINT ADR(A$) I get 2095, but after GOTO 20 I get 2098.  All these results are fixed.  The next PRINT gives 2095 again, the next GOTO20 - 2098.  Is it possible to explain these results?  It is also interesting to know is it possible to write a Basic program that doesn't move its array just after GOTO or PRINT?

Thank you.

 

[vitoco]

The data won't be moved while the program is running. What you see is the effect of inserting me tokens between the program and the data. Those extra tokens are the immediate mode statements (without a line number) you are running, which are temporary stored as line 32768. Of course, if you add more lines to your program, the data will also move to give space for your new code.

 

BTW, if you define big strings or arrays, inserting me statements to your code will be slower. Then, it could be better to run the CLR statement to remove that data area, insert or update your code faster, and avoid a lock bug.

 

Edited August 1, 2021 by vitoco

[TGB1718]

Array addresses in BASIC are not fixed until RUN time, you can never guarantee where the array will be, even between RUN's

[Rybags]

You can use tricks to "relocate" a string, ie make Basic think it's stored somewhere else and has a different possible length vs what it was DIMed as.

This is useful mainly for using string operations to move screen or PMG data.  But the movement described by entering commands or new lines will still happen as described.