Why did AB push the line number and not the address?

[Maury Markowitz]

I'm on page 19 of the Atari Source Book. It shows how the FOR statement pushes an entry containing the line number so the NEXT can find it again.

 

But why a line number? Why didn't they push the address of the line and/or individual statement on the line?

 

I'm reading the MS code on github and it appears that's what they do - well if I'm reading it correctly they pop off until they get to the address and then RTS. I'm not sure I totally understand the stack use though.

[thorfdbg]

58 minutes ago, Maury Markowitz said:

But why a line number? Why didn't they push the address of the line and/or individual statement on the line?

Because that wouldn't work in all situations. For example, if you interrupt the program (BREAK key), edit the program and then CONT, the return address could point into the desert. Basic++ pushes both, the address and the line number, but also a "generation counter". If the generation count differs from the one recorded on the stack, the address might have become invalid and is not used.

[JamesD]

MS BASIC pushes the line # as well.  
I don't think you can continue on it if you add, delete, or edit a line of code anyway.

[Maury Markowitz]

1 hour ago, thorfdbg said:

Because that wouldn't work in all situations.

Sure, but it seems like a HUGE cost to pay!

1 hour ago, thorfdbg said:

Basic++ pushes both, the address and the line number, but also a "generation counter". If the generation count differs from the one recorded on the stack, the address might have become invalid and is not used.

That seems like a simple solution!

[Maury Markowitz]

32 minutes ago, JamesD said:

MS BASIC pushes the line # as well.  

I am looking at the code, it seems to push CURLIN and TXTPTR, isn't that the address into the line?

[JamesD]

CURLIN is line number, TXTPTR is current position

*edit*
In this case TXTPTR is the end of the FOR statement, which is where to continue after the NEXT

Edited July 29, 2019 by JamesD

[+JAC!]

In Atari Basic you can actually change the running program (and hence addresses) at runtime with the ENTER command. Therefore using line numbers makes perfect sense to me.

[thorfdbg]

9 hours ago, JAC! said:

In Atari Basic you can actually change the running program (and hence addresses) at runtime with the ENTER command. Therefore using line numbers makes perfect sense to me.

Basic (as a language) was designed to be very interactive, thus allowing "on the fly program modification". It was one of the "selling points" for making it a "beginner's" language - as you could interactively "debug" the life program. So, indeed, the feature does make sense. There are just better solutions to solve the problem. Basic++ has one, Turbobasic uses a "hash function" to quickly access the line numbers.

[JamesD]

53 minutes ago, thorfdbg said:

Basic (as a language) was designed to be very interactive, thus allowing "on the fly program modification". It was one of the "selling points" for making it a "beginner's" language - as you could interactively "debug" the life program. So, indeed, the feature does make sense. There are just better solutions to solve the problem. Basic++ has one, Turbobasic uses a "hash function" to quickly access the line numbers.

I'll disagree on better and say different. 
The pointer is faster.  The hash function lets you keep existing BASIC functionality.
It depends on what is most important to the person using it.
 

[Alfred]

Well you can always use Basic XL or Basic XE. FAST mode changes target jumps from the line number to the address of the token in the target line. The caveat is that a number of things will "break" fast mode and cause it to go back to line number search mode. Unfortunately Procedures, which are a bit useful, are exempt from FAST processing.

[Rybags]

As an example, C= Basic will do a CLR and also erase the loop/sub stack if you modify the program after a STOP.

 

Other than space, little reason why Atari Basic couldn't have done line # and address.  You could just have a "program modified" flag and if set, the address could be just recalculated from the line # if it's thought to have changed.  Could also have a bitflag that invalidates the stack entry if the return/loop start line has been modified.

Edited August 1, 2019 by Rybags

[JamesD]

Commodore BASIC is Microsoft BASIC.  You can PRINT variables, and modify variables, but you can't modify the code if you want to CONTinue.
 

[thorfdbg]

On 7/31/2019 at 12:06 AM, JamesD said:

I'll disagree on better and say different. 
The pointer is faster.  The hash function lets you keep existing BASIC functionality.

Ehem. The way how Basic++ handles this does allow you to stop the program, edit it, and continue its execution, so there is no user observable drawback. The only drawback is that the stack entry is larger.

 

A common application of this technique are "self-modifying" programs. You printed the new program contents on the screen, including a "CONT" at the screen bottom, then poked the screen editor into auto-linefeed mode and stopped the program. That even works in FOR/NEXT loops or subroutines. Including in Basic++ of course.

Edited August 1, 2019 by thorfdbg

[ricortes]

IMO BASIC was never really intended to be a development system. As others say, it was really just a teaching tool to learn programming. When the only tool you've got is a  hammer, you tend to treat all your problems as nails. It was the only tool a lot of people using home computers i.e. Atari, Commodore, TI et al had to use.

 

My first computer didn't even have a BASIC or an assembler for that matter, just straight machine code on a programmers pad. Certainly that was the case at Atari where much of their programs were cross compiled in assembly for the 2600. 

 

There were a few exceptions of course like CP/M where they had a lot of languages including BASIC available. Professionals still chose things like Pascal which gave Borland rise to prominence in that era.

 

Atari did come out with a BASIC for the 2600 but it ended up being a joke and a bad one at that. Things were really different back then. 

[Maury Markowitz]

On 7/30/2019 at 5:08 PM, thorfdbg said:

Basic (as a language) was designed to be very interactive, thus allowing "on the fly program modification

But that's not true, the original basic, Dartmouth, was a compiler. This became common later, indeed, but it is not clear to me that they ever considered stop-n-go to be important.

[_The Doctor__]

From an educational standpoint, stop and go most certainly was a great advantage.

[JamesD]

5 hours ago, Maury Markowitz said:

But that's not true, the original basic, Dartmouth, was a compiler. This became common later, indeed, but it is not clear to me that they ever considered stop-n-go to be important.

Interpreters became the thing because they required little RAM, fit in a small ROM, and didn't require disk storage.

[Rybags]

Back to the why... another reason would be that it keeps the language code size down.

The same routine which seeks a line can be used for GOTO, GOSUB, NEXT etc.

 

[thorfdbg]

4 hours ago, Rybags said:

Back to the why... another reason would be that it keeps the language code size down.

The same routine which seeks a line can be used for GOTO, GOSUB, NEXT etc.

 

Not really. Did that for Basic++. The line number search requires an additional JSR, the address does not, and the same function is used for NEXT and RETURN, so it does not make much of a difference.

 

The tricky part is that the address is not necessarily valid.

[Rybags]

Other Basics that implement the address method just do an implied CLR/END/POP all runtime stack entries when a modification takes place.

 

I guess that there'd be insufficient free space in the 8K to modify Atari Basic to use addresses as well - and maybe not worthwhile since there's multiple better alternatives around.

[thorfdbg]

4 hours ago, Rybags said:

I guess that there'd be insufficient free space in the 8K to modify Atari Basic to use addresses as well - and maybe not worthwhile since there's multiple better alternatives around.

Hardly. Basic++ fits into 8K and does exactly that. I believe I said this already.

[Maury Markowitz]

On 7/29/2019 at 2:26 PM, JamesD said:

MS BASIC pushes the line # as well.  
I don't think you can continue on it if you add, delete, or edit a line of code anyway.

Ok, so this is ultimately wrong.

 

Yes, it DOES post the line number, but it does so only so it can report the line on which an error might have occured.

 

The actual pointer to the code to run is in TXTPTR, which is the address of the code to run. eval.s uses that pointer to loop back to the top in the NEXT.

 

Which brings us back to why Atari BASIC didn't do this? MS would simply refuse to continue if you changed practically anything, and while this is perhaps going too far, in this case the massive upside of loops would seem to argue that this is a reasonable tradeoff.

[thorfdbg]

I wonder which type of answer you expect. The only way how to get a definite answer is to ask the authors, and other than that, speculations and arguments have been provided in the thread. As stated, I assume that the reason is that SMI wanted to support interactive programming, allowing CONT after editing the program. The interpreter size is not an argument (experimentially falsified).

[FifthPlayer]

I think the answer is more prosaic - they simply didn't have much development time, and so they reached for the most straightforward way to implement line numbers.  The history of Atari Basic is documented by Bill Wilkinson and others; Atari gave them a VERY tight schedule along with monetary bonuses for finishing ahead of time.  And they did.

[Rybags]

Yeah.  And if they'd released something with similar speed to Basic-XE or Turbo Basic then they could have hurt their own game sales.

At the time though it was probably considered fairly fast given that the competition was Apple II, TRS-80 and the PETs - fair enough the slower machines might have had quicker Basic benches but once you started doing graphics or gaming stuff that wasn't necessarily the case.