I'm not exactly sure what's going on with this article and whether it's just the language barrier or something else, but... it doesn't make an awful lot of sense?
'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...
"You can poke new values into the start-of-program pointer to speed up jumps to the end of the program, and speed up loop execution" is pretty tricky. So's "you can poke new values into another pointer to jump to arbitrary statements within a multi-statement line, and here[1] is a 3d maze program that abuses the heck out of this to become a one-liner".
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...
> '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!
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.
ZX BASIC (as far as I know) was not a MS BASIC product, but many of the same techniques were used in MS BASIC. There were books describing the techniques that this blog post mentions, plus a lot more.
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
because Y, X, B, and Z were the most frequently accessed variables, so getting them at the start of the symbol table sped up future look-ups.
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 I
GW-BASIC, and probably other MS BASICs, only looked up destination lines once, then replaced the GOTO code with a direct pointer to the destination. Something similar may have been used for other symbols, but I don't remember for sure?
Guess 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.
I'm not exactly sure what's going on with this article and whether it's just the language barrier or something else, but... it doesn't make an awful lot of sense?
'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...
"You can poke new values into the start-of-program pointer to speed up jumps to the end of the program, and speed up loop execution" is pretty tricky. So's "you can poke new values into another pointer to jump to arbitrary statements within a multi-statement line, and here[1] is a 3d maze program that abuses the heck out of this to become a one-liner".
1: https://spectrumcomputing.co.uk/entry/21001/ZX-Spectrum/1_Li...
It makes a lot of sense to me.
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...
> '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!
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.
ZX BASIC (as far as I know) was not a MS BASIC product, but many of the same techniques were used in MS BASIC. There were books describing the techniques that this blog post mentions, plus a lot more.
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:
because Y, X, B, and Z were the most frequently accessed variables, so getting them at the start of the symbol table sped up future look-ups.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
GW-BASIC, and probably other MS BASICs, only looked up destination lines once, then replaced the GOTO code with a direct pointer to the destination. Something similar may have been used for other symbols, but I don't remember for sure?
Guess 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.
https://github.com/robhagemans/hoard-of-gwbasic
This video about how to program the ZX81 efficiently is also fun: https://www.youtube.com/watch?v=WqVfyyZbIvo
HN effect:
Error establishing a database connection
Rewind the tape, give the head adjustment screw a tiny turn anticlockwise, and hit play again. It'll load fine this time.
Great point!
Or load it over gopher:// with a Spectranet or similar:
https://www.youtube.com/watch?v=TTvrIPzGAFQ
gopher://gopherddit.com
Also maybe sit the database server on something hard like a book or a tray, to allow better airflow underneath it.
Just don’t jostle it when it’s powered on.
Hey hey 16k, what does that get you these days?
RESTORE