Jump to content
IGNORED

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


OLD CS1

Recommended Posts

So we're we arguing over top down vs bottom up programming here? 

Doesn't that depend on the language used? Or not. I just start writing and don't pay attention...as long as everything fit I assume it's ok.

But that's me. I also speed on the highway and open coke bottles immediately after accidentally dropping it or shaking it up... sometimes not smart. ?

Link to comment
Share on other sites

24 minutes ago, GDMike said:

 I also speed on the highway and open coke bottles immediately after accidentally dropping it or shaking it up... sometimes not smart. ?

Supposedly if you tap on the side of the bottle it will dislodge the bubbles clinging to the sides and it won't froth over. Give it a test and report back.

  • Haha 2
Link to comment
Share on other sites

I think there is some merit to the idea that if you have a given static space in VDP memory, building the line number table from the bottom of that space upward and the program storage from the top down would be efficient, but only for the program.  There is also variable storage that has to exist in the same memory.  Now you have three entities which must occupy the same space.  Though, in practice there are more than just three.

 

How TI handles VDP RAM:

0960->		Value stack
 dynamic	String space
 dynamic	File attribute blocks
 dynamic	BASIC symbol table
 dynamic	BASIC line number table
   <-3FFF	BASIC program text storage

 

I imagine this is the result of many hours of tinkering and consideration for factors like program flow and PAD RAM availability for pointers.  In my ignorance I might have suggested splitting the BASIC line number table away from the other BASIC parts, putting it at the bottom of memory and growing it upward.  Simply because the value stack, string space, and symbol table are transient -- that is, these blocks are only in use when the program is running, and are invalidated once the resident program is changed.

 

However, my idea would prevent a PROGRAM file dump of the BASIC program in VDP RAM.

  • Like 3
Link to comment
Share on other sites

8 hours ago, Retrospect said:

I think I can help here, Rich ... this is the post that made Senior Falcon write point 4.

I've placed a little HunchBack Arrow next to the sentence so you can see what he means.rxb.thumb.png.2141d092533b1bd7c96c26fd72c8b4e4.png

 

3 hours ago, GDMike said:

So we're we arguing over top down vs bottom up programming here? 

Doesn't that depend on the language used? Or not. I just start writing and don't pay attention...as long as everything fit I assume it's ok.

But that's me. I also speed on the highway and open coke bottles immediately after accidentally dropping it or shaking it up... sometimes not smart. ?

  • The top-down approach is primarily used by structured programming languages such as C, COBOL, Fortran. On the contrary, the bottom-up approach is preferred by OOP languages such as C++, C#, Python, Java, and Perl.

In the C programming language, the problem statement is first understood and a solution is created after which the main function is created and all the sub-functions are called from the main function breaking the problem into smaller parts. Hence, procedural languages utilize the paradigm of a top-down approach.

 

Top-Down Vs Bottom-Up Programming [Updated in 2021] (codingninjas.com)

 

TI Basic and XB is a procedural language.

What is a Procedural Language? (computerhope.com)

 

Look you want to argue with experts fine, but do not attack me for stating facts.

Link to comment
Share on other sites

7 hours ago, RXB said:

but do not attack me for stating facts

Saying someone is lying is an attack. People will respond in kind. This thread, however, is not about semantics and debate style, but rather about the how line numbering affects program execution performance in TI BASIC and Extended BASIC, and now the technical details therein. I appreciate all of the knowledge and experience here, so let us all try to keep it academic and not devolve into the personal.

 

Anyone holding any grievances is welcome to take them out of my thread.

  • Like 1
Link to comment
Share on other sites

6 hours ago, OLD CS1 said:

Saying someone is lying is an attack. People will respond in kind. This thread, however, is not about semantics and debate style, but rather about the how line numbering affects program execution performance in TI BASIC and Extended BASIC, and now the technical details therein. I appreciate all of the knowledge and experience here, so let us all try to keep it academic and not devolve into the personal.

 

Anyone holding any grievances is welcome to take them out of my thread.

Not just the Line Table but how the programs are entered into memory and how they are processed.

The line number table runs from lowest address to highest address.

And Auto Increment DOES NOT work by going from highest address to lowest address in Assembly or GPL or VDP.

Auto Increment works by lowest address to highest address in Assembly, GPL and VDP.

I do not understand the reason for insisting this is not true? 

Unless something thinks >FFFF is lowest address and >0000 is highest address in memory!

Link to comment
Share on other sites

2 minutes ago, RXB said:

Not just the Line Table but how the programs are entered into memory and how they are processed.

The line number table runs from lowest address to highest address.

And Auto Increment does not work by going from highest address to lowest address in Assembly or GPL or VDP.

Auto Increment works by lowest address to highest address in Assembly, GPL and VDP.

I do not understand the reason for insisting this is not true?

I think the misunderstanding here is across three applications: first, scanning the line number table and, second, moving the line number table and, third, accessing the data in VDP memory through the data register.

  • Like 1
Link to comment
Share on other sites

1 minute ago, OLD CS1 said:

I think the misunderstanding here is across three applications: first, scanning the line number table and, second, moving the line number table and, third, accessing the data in VDP memory through the data register.

1. Scanning line number table happens every time a command like GOTO or THEN line number or GOSUB are used, along with other commands I listed before.

2. The only time the Line Number table is ever moved is when in Edit mode. Program mode never moves any line numbers ever.

3. I have no idea why VDP Memory and date registers were brought up. Other than VDP is used in XB when no 32K is available.

Link to comment
Share on other sites

13 hours ago, OLD CS1 said:

Though, in practice there are more than just three.

 

I imagine this is the result of many hours of tinkering and consideration for factors like program flow and PAD RAM availability for pointers. 

Continued reading in the "Product 359 Design Specifications," Pg. 43:

 

The complications involved with managing the memory can be realized by seeing that there are five independent data structures residing in the same memory area. No conflicts arrise between the crunched program and the string space as the program and its associated line number table always reside in the highest addresses possible and whenever the program is modified by the user the symbol table and string space are destroyed.

  • Like 2
Link to comment
Share on other sites

Just now, RXB said:

3. I have no idea why VDP Memory and date registers were brought up. Other than VDP is used in XB when no 32K is available.

Yes, I brought it up for this exact configuration, working in XB without the 32k expansion, if only to make sure TI BASIC is included in the conversations, per the thread topic.

  • Like 2
Link to comment
Share on other sites

11 minutes ago, RXB said:

The line number table runs from lowest address to highest address.  This is a correct statement.

And Auto Increment DOES NOT work by going from highest address to lowest address in Assembly or GPL or VDP. This is also a correct statement.

Auto Increment works by lowest address to highest address in Assembly, GPL and VDP. This is a correct statement.

I do not understand the reason for insisting this is not true? All the above is true.

Unless something thinks >FFFF is lowest address and >0000 is highest address in memory!

This is like something out of Kafka. Look at the code you posted. It clearly shows that the line number table is searched  from the lowest address to the highest address, and it shows that auto increment is used.

 

  • Like 1
Link to comment
Share on other sites

Yes I know all this I have been working on XB Source for 30 years now.

And the destruction of the Symbol Table and string space are due to the Garbage Collection routine but then the Symbol Table is rebuilt elsewhere.

As for TI Basic with my modification to RXB I can run all but 3 TI Basic programs with no modifications.

The 3 TI Basic programs all are exploits of peculiar  to TI Basic and crash XB.

I did eliminate one of these but the other 2 are only doable in TI Basic.

 

Link to comment
Share on other sites

I never once said the Line Number table is searched from Highest address to Lowest address go back and look.

What I said was when you enter a program in EDIT mode it saves the lines in the order you typed them in.

That does not modify the line number table but where the line is located even if out of sequence the order you typed like 1100 then 100.

Link to comment
Share on other sites

6 hours ago, RXB said:

I never once said the Line Number table is searched from Highest address to Lowest address go back and look.

 

     Your post #36:

Page 83 and 84 lay out XB line number table and actually it is searched from highest address to lowest address so auto increment is not able to be used.

 

     Your post #50:

This is just the GOTO and ON ERROR search, the GOSUB is below this one and there are others, they do use some of the same routines.

But there are way more then one LINE NUMBER SEARCH ROUTINE.

You are correct this is a mess as they go from highest address to lowest address for programs, I have no clue why as it looks insane.

Anyone with a brain cell would start from lowest address and go higher address as that would allow for *Register+ auto increments.

Instead they have to go backwards DOWN in memory all the time making sure it slows the XB reading down on purpose.

You could not be more ass backwards to slow XB or TI Basic down.

     Here you talk about the line number search routine, then "they go from highest address to lowest address for programs," and that it will "slow XB or TI Basic down." The average reader would get the impression that the entire post was about the line number search routine.

 

     Part of your post #59:

This would only affect the EDITOR setting up program to insert a line or line number.

Program execution would be better as instead of jumping backwards constantly like XB does now it would always be moving forward.

    It should be clear to even the most casual user that executing a program is not the same as editing it.

 

     Part of OLDCS1's post #70:

But, as Rich pointed out, scanning the table is not as efficient as the downward scan does not take advantage of the automatic increment function of VDP register operations.  This means the BASIC interpreter must give the VDP a new address every time it pulls from the line number table, whereas if the table was searched bottom-to-top, the interpreter could just keep reading from the VDP.

     Although these are not your words, it is clear that OLDCS1 got this erroneous idea from what you wrote. This would have been a fine time to disabuse him of his erroneous notion, but not a peep from you...

 

     Part of my post #71:

1 - Why would anyone think the line number table is being scanned downward? With even a rudimentary understanding of assembly you can look at the the code Rich posted in post #49, which clearly shows the table being scanned in an upward direction. This means autoincrement can be used (and it is), which seems to be the biggest complaint.

     No response from you to point #1. Yet another missed opportunity for you to clear the record and show that you either misspoke or were misunderstood.

 

  • Like 1
Link to comment
Share on other sites

At first I attempted humour to de-rail the argument, then I tried to help Rich see where he might have triggered a negative response, and now I've come to the awkward realisation that somehow, somewhere, this entire thread got shitted up.  That's not good.  

  • Haha 1
Link to comment
Share on other sites

Getting back on the subject, (at last) I made a ridiculous program of 1601 lines.

1 X=X+1::GOSUB 2::GOTO 1

2 RETURN

3 !

4 !

(Lines 3=1599 are comments)

1599 !

1600 X=X+1::GOSUB 1601::GOTO 1600

1601 RETURN

In 30 seconds:

RUN 1 loops 125 times

RUN 1600 loops 3421 times.

Note that there is 1 GOSUB and 1 GOTO per loop.

So there is definitely a speed advantage when going to a higher number line.

Obviously, the example program is a little extreme.  To fit 1600 lines into 24K, each line would average 15 bytes, and 6 of those are used for the line #, length byte and trailing zero.

In the real world a really long program might be 400 lines, which would average around 54 bytes of code per line, so this effect would not be so extreme.

  • Like 5
Link to comment
Share on other sites

Oh poor pitiful me ... I bought a bad advice in th 80s ... "Start your program with 100 GOSUB 10000" and do all the initializations there, and start the main-loop in 110" ... But is this really the reason my programs where slow? I guess not ... 

 

Would there be any difference if you had "3 X=X+1::GOSUB 1601::GOTO 3" with "RUN 3"? And if you pasted this program not sorted but randomly or in reverse order? So much more to explore...

Link to comment
Share on other sites

19 minutes ago, SteveB said:

Oh poor pitiful me ... I bought a bad advice in th 80s ... "Start your program with 100 GOSUB 10000" and do all the initializations there, and start the main-loop in 110" ... But is this really the reason my programs where slow? I guess not ...

Give the results of the experiments, the slow-down will not be noticeable for one-time called sub-routines, like initialization routines which get called once a game it not once a program.  It is the repetitive sub-routines like fetching user input, making calculations for movement, etc.  The marquee for my Tiles game runs faster with the user input routine at the front of the program versus at the back, it makes several sub-routine calls (GOSUBs) during its running.

  • Like 1
Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...