Error establishing a database connection
https://www.youtube.com/watch?v=TTvrIPzGAFQ
gopher://gopherddit.com
For instance, the symbol table is built as each variable is encountered, and it is not ordered. Thus, it was common for the first line of a BASIC program to be something like:
10 Y=X=B=Z=1
Another thing: I'm pretty sure MS BASIC was smart enough to check if the GOTO or GOSUB line number was greater than the current line number, and if so, it would seek the target line from the current line, instead of the start of the program.
WANG 2200 BASIC-2 had an optimization for DEFFN statements. There was a small, fixed-size table, something like 16 entries, to hold a pointer to the first n DEFFN statements. Most programs used less than this limit. When an "FNX(...)" or whatever was encountered, it would search that DEFFN table, which then had a direct pointer to the line where the DEFFN was located. If there were more than 16 DEFFN statements, it would then have to do a linear search through the program text to find it.4
[EDIT] I forgot to mention, the article mentions that NEXT and RETURN also cared about line number placement. I haven't studied ZX BASIC so maybe it is different, but in MS BASIC and WANG BASIC there is a stack frame that contains a pointer to the head of the loop or the return point, respectively, for those two cases. Just storing a line number would be insufficient because the FOR body and the RETURN point might be in the middle of a line, eg
200 X=X+1:GOSUB 1000:FOR I=1 TO 20:T=T-B(X):NEXT IGuess the ZX BASIC did not do that, or it would have improved the measurements seen in the article?
BLUE Book of GW-BASIC is full of details and tricks like that and some of it probably is useful for other BASICs as well.
ZeroConcerns•1mo ago
'Tricks' like 'not including too many comments' were already well-known from day one of the ZX line (which started around 1980) because, well, you had 1K, 16K or 48K or RAM to work with, so every character counted!
Also, you were painfully aware of the performance of inner/outer loops, because, absolutely, a sub-3 MHz clock speed doesn't leave many other options. Other than to migrate to assembly coding, which was where most serious Sinclair coding took place.
The article is right about one thing, though: the Sinclair BASIC interpreter was a work of minimalist art, as was the hardware. "Sure, let's multiplex the audio-in line with the video sync signal, so we can save a pin on the ULA" is not something that gets a lot of consideration these days...
egypturnash•1mo ago
1: https://spectrumcomputing.co.uk/entry/21001/ZX-Spectrum/1_Li...
Zardoz84•1mo ago
But that GO TO/GO SUB target position in the code list matters, because does a linear search (so the no use comments, isn't only about wasting RAM), was new for me. And I toyed with a ZX Spectrum as child.
amiga386•1mo ago
They key problem is that GO SUB and GO TO are not instantaneous like a CALL or JP instruction would be in Z80. The BASIC interpreter does a linear scan through the entire source code, until it reaches the specified line number. Every time you want to jump or call.
That's why this article is called "Efficient Basic Coding"... all the "tricks" are about moving the most frequently called code to the lowest line numbers, so the interpreter spends as little time scanning the source code destination line numbers as possible.
The second article in the series is on a theme, where variables aren't indexed either, the interpreter scans through each variable in turn until it finds the one with the name referenced in the source code... again you want to define them in order of most frequently accessed...