5 ms·
They didn't work like modern interpreters, which basically compile the program into bytecode and then interpret the bytecode. They would do simple very simple p
by david-given 12y ago
They didn't work like modern interpreters, which basically compile the program into bytecode and then interpret the bytecode. They would do simple very simple parsing of the program, mostly just tokenising it, and then more or less execute each Basic statement directly. (Sinclair Basic's wacky keyword-at-a-time entry system meant they didn't need to ship a tokeniser.)
So:
10 LET I = 10
20 LET I = I + 1
30 GOTO 10
The program counter would point at the start of line 10; the interpreter would see LET (mandatory in Sinclair Basic) and know a variable name was next; it'd read that; it'd read the equals sign; then it would read the expression and evaluate it on the fly. Then the program counter would be pointing at the end of line 10, so it just advances over the line number, and it's ready for line 20. etc, etc.
Line 30 would read the GOTO, then read the line number, then reset the program counter to the beginning of the program and scan through looking at line number headers until it found the right one. Yes, O(n). Yes, you put most used subroutines at the beginning of the program for speed.
So the entire run-time state is a program counter, a couple of fixed-size stacks for FOR...NEXT and GOSUB...RETURN, and your variables. I've no idea how Sinclair Basic stored them, but BBC Basic used a hash table that was immediately after the end of your program. Strings were a problem because they could change size; Commodore Basic had the world's slowest garbage collector. BBC Basic just fragmented and ran out of space. I don't know how Sinclair Basic handled it.
If you're interested, the entire ROM is disassembled here: http://www.wearmouth.demon.co.uk/zx81.htm http://www.wearmouth.demon.co.uk/zx81.htm
- lifeisstillgood 12y agoOh my god - that's we we had line numbers ! To reduce parse complexity - FFS!!! That's amazing. Why am I so blind?
- gress 12y agoNot quite - line numbers were also the text editor.
- david-given 12y agoThey actually make for quite a decent IDE --- it's a really cheap and easy way to allow arbitrary insertion at any point without needing the complexity of a full text editor. You really need a RENUMBER command, though (which BBC Basic had) or else you sometimes find yourself unable to subdivide numbers.
- Someone 12y ago"I've no idea how Sinclair Basic stored them, but BBC Basic used a hash table that was immediately after the end of your program." I expected that Sinclair Basic would have a rule that variable names have one significant character, and reserved space for 26 integers A% through Z%, 26 strings A$ through Z$, and forget about floating point, but reading http://www.worldofspectrum.org/ZX81BasicProgramming/chap06.html http://www.worldofspectrum.org/ZX81BasicProgramming/chap06.h..., that isn't true; this language even allowed spaces in identifiers. At the same time, we have (same link): "You will get a report 2/0, & looking up 2 in appendix B, you will see that it means 'variable not found', So. This enormous 8kB ROM wasn't large enough to hold error messages. And, reading http://www.cs.columbia.edu/~%20sedwards/classes/2006/w4115-fall/reports/zx81basic.pdf http://www.cs.columbia.edu/~%20sedwards/classes/2006/w4115-f..., it seems that loop and stir g variables had to be single-letter (yes, your program had at most 26 strings. Not that much of a limit if you have a few hundred bytes of RAM for your program and your data) That PDF also gives some more limitations of the language, claiming that it wouldn't do complex expressions such as 10 let a = 2 * a + 1
- david-given 12y agoEverything you never wanted to know about ZX81 Basic's memory layout! http://www.worldofspectrum.org/ZX81BasicProgramming/chap27.html http://www.worldofspectrum.org/ZX81BasicProgramming/chap27.h... ...wow. The framebuffer is between the program and the variables? And as the program changes size, and the screen changes size, it relocates everything above there? No wonder editing lines in a big program is so slow... Also, that mention of the calculator stack? That's used by an embedded Forth-like language used to do floating point operations; which is why Sinclair Basic's trig functions are so appalling.