Why does this BASIC program declare variables for the numbers 0 to 4?

Question

On pages 150 to 154 of William Tang's (1982) Spectrum Machine Language for the Absolute Beginner, there are these lines of code. (Note GOTO 9000 is the first non-REM statement in the program).

9000 REM 
9010 REM initialisation
9020 LET ze= PI - PI: LET on = PI / PI: LET tw = on+on: LET tr = on+tw: LET fr = tw+tw: LET qk = 256: LET mr = 2020 : LET ln = 200

So following through the first five variables, ze represents 0 (zero), on 1 (one), tw 2 (two), tr 3 (three) and fr 4 (four). These variables are then (mostly consistently) used throughout the program where the numbers one to four are needed, though at least once on+tw is used for 3.

Note that 0 and 1 are derived by calculations based on π!

My question is: Why did the programmer choose to do this? I can think of two possible reasons, though there are almost certainly more.

1. Obfuscation in the interests of copyright protection.
2. Making sure a novice programmer types in the whole program from beginning to end before any part of it works. (As I said above, line 9000 is called straight away, and the program finishes at line 9180).

To avoid complete speculation, but aware that we are unlikely to get the author's express opinion, it would be good to hear about common practice / people who did explain this practice in the era of typed program listings, or to see a provable performance benefit from code like this.

Answer 1

These tricks are usually done to increase speed or reduce space. For most (especially Microsoft) BASIC, constants are stored within a tokenized line as ASCII (as entered), and converted to a floating point number every time they are evaluated. This is a time consuming process. Assigning the number once to a variable to be used thereafter will skip this part and save quite some time.

Sinclair (Floating Point) BASIC is better than that. While it also includes the number the same way (*1), it is followed by the token 0x0E (*2), and the next 5 bytes storing the constant in floating point format. Sinclair BASIC does now only need to read past the ASCII until the 0x0E and take the FP without the need of conversion - so speed is not an issue.

But looking at the encoding shows that every time a constant is used it will take at least 7 bytes of program memory:

• 1 Byte for the ASCII representation (more for numbers outside the integers 0..9)

• 1 byte 0x0E

• 5 byte floating point representation

A variable name is stored within the program as its ASCII representation. So a two letter name (like on, tw, ...) occupies just two bytes (*3). Thus any occurrence of on is just two bytes instead of seven. That's five bytes saved each time on is used.

Of course, this comes with an offset of assigning the variable, which is 5 bytes plus the expression used. So with LET ze=0 that would be 12 bytes, meaning that already using the variable three times will save space.

Using ze=PI-PI saves even further, as this takes only 3 bytes, so the second usages of ze will yield saved program space. Similar for all the other calculations. It's all about avoiding constants and replacing them by shorter encoded calculations.

In fact, these optimizations also offer some hints about the age of a program, or at least the time its programmer learned the tricks. PI-PI was eventually the first discovered and used a lot - until someone came up with the idea of NOT PI which also results in zero, but needs one byte less. SGN PI gives one. Two is a bit more complex, but on+on is as good as SGN PI+SGN PI (both 5 bytes) - later INT EXP SGN PI with only 4 bytes was discovered. Three again is just INT PI, and so on.

The origin of these very Sinclair BASIC specific tricks starts with the ZX81 (the same as the ZX80, but with Floating Point BASIC). Here program space was scarily rare, thus every byte saved was worth the extra effort - much more than later on with the 'huge' RAM the Spectrum offered (*4).

Use of these tricks is a good hint that a programmer started out on a ZX81.

So I'd say that guy did start on a ZX81, and the above program was written early on - and just moved to the Spectrum later.

---

*1 - Well, not as entered, but as if it had been listed after being converted to float, and back to printable.

*2 - While this structure was introduced with the ZX80 FP BASIC/ZX81, 0x7E was used there. When creating Spectrum BASIC it was changed to 0x0E to allow its character set to be (mostly) ASCII compatible.

*3 - It's a bit more complex, so dig into BASIC tokenization and variable list handling if you really want to know the fine print.

*4 - Then again, we all know that there is never sufficient RAM.

Answer 2

The answer by Raffzahn is very good, except that I disagree that ZX80/81 background is all that important and I also feel he missed one important trick.

I personally know most of these tricks from studying BASIC loaders for ZX Spectrum games. You see, yes, Spectrum has more memory, but when the machine code program is loaded, it was absolutely not uncommon to set up the stack at 24576-1 or 24320-1 or even 24064-1 (this was especially true with Multiface snapshots repackaged as hacked versions of games). With BASIC memory on unexpanded Spectrum 48K starting at 23755, this leaves you with no more RAM to Spectrum BASIC than the amount of RAM you have on ZX81.

So, many loaders started with a code like this:

10 INK NOT PI: PAPER NOT PI: BORDER NOT PI: CLEAR VAL "24063"

Raffzahn already explained NOT PI. VAL "number" is another very common approach. Indeed, by default a number with X digits is stored in ZX BASIC using X+1+5 bytes. Number 24063 would normally occupy 5+1+5=11 bytes, whereas seemingly inefficient VAL "24063" only takes 3+5=8 bytes.

VAL works great for single digit numbers too. VAL "2" is also 4 bytes and much clearer than ugly INT EXP SGN PI. There is absolutely no need to use any combinations longer than 4 bytes (so SGN PI + SGN PI is interesting, but ultimately useless).

One last bit of probably irrelevant trivia. One can also create binary-edited basic programs, which work but do not confirm to what can be inputted using BASIC line editor. Using this, any number (floating point included) can be stored as exactly 1+1+5 bytes, i.e. there is technically no need to spend more than 7 bytes per constant. So, even though CLEAR VAL "24063" is easier to type in, the most size-efficient loaders would typically have instead command CLEAR 0, stored as

DB #FD,'0',#0E,0,0,#FF,#5D,0 ; the number occupies 7 bytes only

This works because the actual ASCII representation of a number is only used by the editor; the interpreter only cares about binary representation after #0E.

Update

In fact, even a cursory look through the book indicates that the authors are working with 16K ZX Spectrum in mind, which actually makes a lot of sense for 1982. For example, on p.9 they discuss "Nevertheless, such assemblers typically require 6K of memory, and are therefore of limited use on 16K machine. The Spectrum display takes up 7K of memory, and after loading the assembler you may have only 4K of memory left for you assembly language program."

Even more relevant to the programme "EZ-Code" listed on pages 150 to 154 (which is a kind of machine code editor in BASIC) is the discussion on p.145 of the assumed memory map. "Your program module must not be greater than 800 bytes or more than 200 instructions. You cannot load the final program below memory 31499 (in order not to wipe-off the EZ-Code program)". Clearly, the authors are working under assumption here that there may be no memory above 32768.

Thus, the memory is quite tight because they are assuming 16K Spectrum. Hence, the likely need to economize space in their BASIC code.