Jump to content
OLD CS1

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

Recommended Posts

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

Share this post


Link to post
Share on other sites

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. 😂

Share this post


Link to post
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

Share this post


Link to post
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

Share this post


Link to post
Share on other sites

Also good to know...

If you happen to be in a falling elevator ... jump up real hard just as the car is about to crash, and you'll be fine...

859cdb6b0df0a8c041fa5651159ac1e9.thumb.jpg.ffabd356718b40a87495c31e23fbbb38.jpg

...Time to install glass floors in all elevators!

  • Like 1
  • Haha 1

Share this post


Link to post
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.

Share this post


Link to post
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

Share this post


Link to post
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!

Share this post


Link to post
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

Share this post


Link to post
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.

Share this post


Link to post
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

Share this post


Link to post
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

Share this post


Link to post
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

Share this post


Link to post
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.

 

Share this post


Link to post
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.

Share this post


Link to post
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

Share this post


Link to post
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

Share this post


Link to post
Share on other sites

I guess lee wasn't fazed. He's seen worse, like trying to get me to understand SAMs.. poor lee.

Sorry for the abuse on my behalf.

Share this post


Link to post
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.

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...