A perfect example of this has to do with how the program skips over the remainder of a line.
The interpreter reads a byte at a time until if finds the 0 (zero) line terminator, then it increments the current position by 1 to point to the next line.
This happens for REM, ON GOTO, ON GOSUB, IF THEN, etc... so obviously it will also happen on lines that use IF THEN ELSE.
So how do we speed this up?
The interpreter stores program lines in the following format:
16 bit word pointing to next line
16 bit word holding the current line number
So how do we speed this up?
The interpreter stores program lines in the following format:
16 bit word pointing to next line
16 bit word holding the current line number
tokenized BASIC code for the line
0 line terminator
Even thought the interpreter has access to a pointer to the next line, it does not use it except when searching for a line number.
A faster way to deal with this is to save the pointer to the next line when BASIC starts interpreting a new line, and then load that pointer instead of searching for the end of the line.
This change adds an extra 4 clock cycles at the start of each line, but calling the search for an end of line marker might take a hundred clock cycles, and removal of a related opcode in the search function reduces each call by 2 clock cycles. If the interpreter has to search for ":" multiple times, it's even faster. The longer the lines and more complex the code, the greater the improvement in speed.
There is a drawback to this. It requires two more bytes on the direct page to store the pointer to the next line. But BASIC doesn't directly allow access to that, and modern RAM expansions provide more direct page space anyway, so it shouldn't prove to be too much of an inconvenience.
Even thought the interpreter has access to a pointer to the next line, it does not use it except when searching for a line number.
A faster way to deal with this is to save the pointer to the next line when BASIC starts interpreting a new line, and then load that pointer instead of searching for the end of the line.
This change adds an extra 4 clock cycles at the start of each line, but calling the search for an end of line marker might take a hundred clock cycles, and removal of a related opcode in the search function reduces each call by 2 clock cycles. If the interpreter has to search for ":" multiple times, it's even faster. The longer the lines and more complex the code, the greater the improvement in speed.
There is a drawback to this. It requires two more bytes on the direct page to store the pointer to the next line. But BASIC doesn't directly allow access to that, and modern RAM expansions provide more direct page space anyway, so it shouldn't prove to be too much of an inconvenience.
No comments:
Post a Comment