POP from Applesoft BASIC and Atari BASIC

[mobluse]

There is a flow control command in Applesoft BASIC that might be good to have in X16 BASIC:

POP

Removes one address from the return stack, i.e. converts last GOSUB into a GOTO.

POP could be useful in more advanced BASIC programs. Maybe this could be solved using POKE, but it would be easier with a BASIC command, and then more old Applesoft BASIC programs could run on Commander X16. I did find two programs that uses POP:

https://github.com/inexorabletash/jsbasic/blob/master/samples/sample.nuclear.txt

https://github.com/inexorabletash/jsbasic/blob/master/samples/sample.pacman.txt

https://www.calormen.com/jsbasic/reference.html

https://www.landsnail.com/a2ref.htm

How is POP useful in debugging?

[Snickers11001001]

I just looked at the code for pacman you linked.  Frankly, it seems to me that POP wasn't really crucial and in fact was used in some convoluted branching choices that could have been avoided.  There's a half dozen other ways to do the same thing without converting a gosub to a goto.    

Glancing at "Mapping the C64" book from the 'golden days' I was able to confirm that  Basic 2.0 actually uses the 6510 HARDWARE STACK in the processor as the BASIC stack, and there are a ton of kernel and basic routines that are tinkering with the stack and moving the SP around to do housekeeping etc.    

Being practical, look at it this way:    In like 8 versions of Commodore BASIC, from the several variations in the 1970s CBM PET, to the VIC20, to the C64; then onto the PLUS4/C16, the C128 and even the unreleased C65, the Commodore folks never added anything resembling the Applesoft  POP to the Commodore BASIC.   

My guess is that to some significant extent, this would been because of both the risks inherent in messing with the Jenga Tower of stack management  and the perception that the command addresses a largely avoidable coding choice.     

Just my two cents.  

[Scott Robison]

While I am not suggesting any particular enhancement, I wrote a scripting language for PCBoard almost 30 years ago. It had a "compiler" that generated tokenized / crunched form of the source, then the run time executed the tokens, directly inspired by BASIC.

Anyway, it didn't have lots of fancy control structures, as I intended for it to be familiar to those who would have some background with BASIC and batch file programming, but I did include a "variable stack" that could be accessed with push and pop. The idea was to support the sort of "low level" mechanisms in a high level language so that later versions of the compiler could generate higher level constructs (such as while loops and user defined functions) using just the low level features already available, thus the compiler would be able to generate code that could run on older versions of the run time.

I never realized that Apple BASIC had a POP, even though it isn't directly comparable to what I did with my push and pop which worked on a software stack, not the processor stack. Still, I think something like that as an extension to BASIC could be useful to synthesize parameter passing that is currently missing from 8-bit forms of BASIC.

Of course, one could easily create their own stack via dim, then using an variable to index the top of stack...

[mobluse]

POP also exists in AtariBASIC:

"If a GOSUB does not have a RETURN, for instance, the stack will still hold the return address. This can be cleared with a POP so as not to cause confusion later. It must be used in the execution path of the program, and must follow a GOSUB not using a RETURN. It is normally the sign of a badly designed program, but is useful in debugging." https://www.page6.org/archive/issue_16/page_43.htm

You cannot change the machine stack pointer from BASIC so you need a machine code routine. If it is possible to read the stack pointer from BASIC you could GOSUB 99, swap the two top elements using PEEK and POKE, update the top element to the next next line in BASIC using PEEK and POKE and RETURN twice. That would have the same effect as POP or SYS699 in the program below. Maybe some other solution without machine code is possible.

A person in a Swedish C64 forum, bjonte, solved the problem using machine code for C64 and VIC20:

Code: Select all

0 fori=0to19:reada:poke700+i,a:next:data104,133,251,104,133,252,186,138,24,105
1 data7,170,154,165,252,72,165,251,72,96
10 gosub100
20 print"finished":end
100 gosub1000
110 print"not here!"
120 return
1000 print"now it happens!"
1010 sys700
1015 sys700
1017 sys700
1020 return

bjonte used https://archive.org/details/Compute_s_M ... mmodore_64 and https://archive.org/details/COMPUTEs_Ma ... blications as references.

POP comes from Apple Integer BASIC by Steve "Woz" Wozniak, and then the later floating point Applesoft BASIC was made backwards compatible with that. 

Anyway, now it is possible to port some Applesoft or Atari BASIC programs with POP to C64 or VIC20.

How is POP useful in debugging?

[kelli217]

If something goes wrong inside the subroutine, you might not want the program execution flow to return to the calling GOSUB (or, more specifically, to the statement following it). You might want to do some error-handling, such as outputting an error message.