What are the impacts of line numbering in BASIC/XB on execution speed?

[speccery]

This is an interesting thread despite venturing off-topic quite a bit...

As background, I have now started to work on a Basic interpreter for my StrangeCart project, and as part of that dived into the way basic stores the programs. I posted a video of the current result of my work - it enables now listing of Basic programs with the StrangeCart processor. The StrangeCart also makes it possible to override the console GROM content, so it would be possible to modify how the GPL code works there.

 

But to my point: the crunched basic code uses the token 0xC9 to describe line numbers. The token C9 is followed by two bytes, containing the line number as 16-bit integer. These line numbers are then searched for in the line number table, as has been discussed in depth in this thread. An idea from ZX Spectrum Basic could be borrowed here - I believe it stores pointers to destination addresses in the basic program code. Thus TI Basic could be speeded up simply for example this way: when during program execution the token C9 and a linenumber is found, the search during line number table occurs as usual. Once the target is found in the line number table, the token C9 could be replaced with another token, let's call it FA, followed by a pointer to the line number table of the destination line. Thus there would not be a need to search for the destination line address anymore, as it can be retrieved from the line number table. This would take the same amount of space as the C9+line number, but the searches would only take place once. After that all goto/gosubs would execute with the same (maximum) speed. it would still be possible to list the destination linenumber, since the pointer to line number table enables that. Of course, before subsequent editing is done, a pass through the stored code would be needed to replace the FA tokens with C9 again, since the pointers would get broken whenever the program or line number table changes.

[1980gamer]

So, I have little clue as to what you are all talking about...

But I will toss a penny in the fountain anyway!  Opinions are like....  you know, everyone has one.

 

First, I was under the impression that data statement belonged at the end of the program.  ( others must have done some of the same reading BITD )

I hardly ever followed this practice, as I never designed and built.  I had a concept and started.  Oh, I need this and that...  let me res 100,100 to make room....  etc.

 

Second, It seems to me, in 1981 when we used the TI as the editor/entry system.  The method used may have been chosen to make editing bearable.  (remember how painful it is to edit on the TI, maybe it would be worse!)

 

Third, the execution example provided is disturbing to me....  Holy $h!t     Do I care if I am compiling?   Seems like no.

But with all the stuff being flung and my lack of understanding of all of this, can a clear guideline be compiled as to how we should layout our programs?

 

Forth, I don't know if/how the order of line entry impacts me?  As I typically use Notepad and Paste it into Classic99.  Even if I do some editing in classic, I ultimately dump it to notepad at some point and paste it back at some point.

 

I certainly would like to write the fastest version of anything I do.  Even for testing prior to compiling.  Testing faster code is better than slower code!

 

Anyway, that may have been more of a nickle than a penny.

[+OLD CS1]

@1980gamer

1. As you say, I believed that was more a style choice than anything else, though see #2.  I have generally put my DATA statements near the point where they are used, if only for readability.  I do recall in a number of places reading as you describe.  Perhaps there are a dialect or two which require this -- I do not know for sure.
2. Perhaps.  In many programs with which I have worked, the DATA statements encode character definitions, sound effects or musical tone lists, level data, &c.  These are things which would be static when complete but likely to change during development.  As noted in several places, the entry order of lines in the TI BASIC editor is how they appear in the program storage area.  Thus entering your data last and then editing it as needed would be much quicker, as the only thing moving around in memory will be the line number table and whatever minimal code follows your data.
3. If you are compiling, then none of this matters.  The compiler will take your program and build an entirely new construct.  Even if the compiled output is just as out-of-order as the input (I do not know how the compiler works at this level,) the speed of the compiled output would all but eliminate any execution delays.  Which, as discussed, is minimized in TI BASIC as it is by the use of the line number table.  The line number table is always in order, so the stored program can be in as much disarray as your kid's bedroom closet and it will execute just as fast as if it were entered in perfect line number order.
4. The largest time delays imposed by the TI BASIC are upon the programmer in the editor.  Once his suffering is complete, the user receives a program which runs as fast as TI BASIC can execute it.  The editing factor is obviated by the luxuries of our modern editing tools, as you described: using Notepad++, Classic99, and structured language interpreters like TIdBiT or TICodEd, &c.

Trading nickels, the ultimate execution speed of your TI BASIC program is going to depend upon your programming style, which is going to be modeled after how BASIC executes its bits and bobs.  Thus, the questions of: where in the program should I put sub-routines?  Are mathematical formulas faster than IF-THEN-ELSE, or ON-GOTO/GOSUB?  Are strings faster than numbers, or vice-versa, for which particular task?  And so on.

 

Of course spaghetti code will have an impact on execution speed as the interpreter has to bounce around the line number table every time program flow is changed.

 

We also have the benefit of source code in various forms and from various sources, especially the tireless dedication of @RXB and the immense wealth of knowledge in the TI Tech Pages, so we could spend some time perusing and determine how this all works.  But, there is some amount of fun in the reverse-engineering of just trying something to see what happens.