Jump to content
IGNORED

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


OLD CS1

Recommended Posts

2 hours ago, RXB said:

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.

I do not understand your indignation over this code. Yes, the line number table is arranged in a way that may seem to be backward to you, but it seems fine to me. Let's say you are entering lines 1,2,3. Starting with line #1, the XB code is put into memory, then #1 is added to the LNT. Enter line 2 and the LNT must be moved to make room for the line 2 code, then #2 is added to the LNT. Enter line 3 and the LNT (lines 1&2) are moved to make room for the line 3 code, then line 3 is added to the LNT. No matter what the order of the LNT is, there has to be provision for inserting a line number in the LNT.

The line number search starts at the highest line number and works its way down to the lowest. Why is this a problem? You have to start somewhere and this has no more disadvantages than starting at the lowest number.

As far as not using auto increment, what do you think these lines do?

  1278 6784 D0F2         MOVB *R2+,R3           2nd byte match?   

  1282 678E 9232         CB   *R2+,R8           2nd byte match?   

  1284 6792 05C2  GOT33  INCT R2                Skip line pointer  

  1287 6798 D0F2  GOT35  MOVB *R2+,R3           Skip 2nd byte of line #   

 

  • Like 2
Link to comment
Share on other sites

4 hours ago, senior_falcon said:

There sure is. You can see this easily when pasting a long program into Classic99. It starts out pretty fast, but as the program grows the lines take longer and longer to enter.

 

It's kind of fun to watch the heat map when doing that with a long program :)

 

  • Like 3
Link to comment
Share on other sites

2 hours ago, senior_falcon said:

I do not understand your indignation over this code. Yes, the line number table is arranged in a way that may seem to be backward to you, but it seems fine to me. Let's say you are entering lines 1,2,3. Starting with line #1, the XB code is put into memory, then #1 is added to the LNT. Enter line 2 and the LNT must be moved to make room for the line 2 code, then #2 is added to the LNT. Enter line 3 and the LNT (lines 1&2) are moved to make room for the line 3 code, then line 3 is added to the LNT. No matter what the order of the LNT is, there has to be provision for inserting a line number in the LNT.

The line number search starts at the highest line number and works its way down to the lowest. Why is this a problem? You have to start somewhere and this has no more disadvantages than starting at the lowest number.

As far as not using auto increment, what do you think these lines do?

  1278 6784 D0F2         MOVB *R2+,R3           2nd byte match?   

  1282 678E 9232         CB   *R2+,R8           2nd byte match?   

  1284 6792 05C2  GOT33  INCT R2                Skip line pointer  

  1287 6798 D0F2  GOT35  MOVB *R2+,R3           Skip 2nd byte of line #   

 

Only that only works on SECOND BYTE not the first byte.

After all XB and Basic programs start at High end of memory and work toward the lowest address.

Do you load Assembly like that? Do you load Object files like that? Do you do this in ANY LANGUAGE?

If there is one please show me.

 

Instead of having to move the lowest address lines to even lower address to insert a line you could just add a line like you would in a text editor.

Do you type SINCERLY YOURS first then work your way up in Word or Notepad, NO YOU DO NOT!

Everyone starts at top and works down just like they go left to right unless you are in Japan going Right to Left!

Who starts at bottom of page and goes up?

  • Like 1
Link to comment
Share on other sites

Going right to left seems to work fine for the Japanese. But OK, lets humor your idee fixee for a moment. First of all, surely you must agree that there must be a line number table. Without that you would have to look through the entire program to find where the code is that you want to GOTO and I can guarantee that would not be a performance enhancer.

Instead of starting at >FFE7 and working down in memory, let's start at >A040 and work our way up.

In my 3 line program example we enter line 1. The code goes starting at >A040 and after the code the line number table containing only line #1.

Enter line 2. Now the line number table has to be moved, the line 2 code added after the code for line #1 and line #2 is added to the LNT.

Enter line 3. Again the line number table must be moved, the code for line 3 added after the code for 1 and 2, then line #3 added to the LNT.

You can see there is no advantage compared to the normal way.

You can work out for yourself how it would go if the line number table was at >A040 followed by the code. That is even worse because there is all the code must be moved to add an entry to the LNT.

You could have the code at >A040 and the line number table at >FFE7. That would mean fewer bytes to move when entering code, but then how do you save the program with it split in two pieces?

 

Remember that the subject of this thread is execution speeds. None of the scenarios above would make any difference in execution speed.

  • Like 2
Link to comment
Share on other sites

1 hour ago, Retrospect said:

I'm 44 years of age.  45 this September.  And it took me till that age, reading an entry in AtariAge Forums, to discover the Japanese start from right to left. They did not tell me this in school.  

I lived in Japan at home port Yakuza and Yokohama in the 1970s, often took trips to Tokyo and other major cities.

  • Like 2
Link to comment
Share on other sites

4 hours ago, senior_falcon said:

Going right to left seems to work fine for the Japanese. But OK, lets humor your idee fixee for a moment. First of all, surely you must agree that there must be a line number table. Without that you would have to look through the entire program to find where the code is that you want to GOTO and I can guarantee that would not be a performance enhancer.

Instead of starting at >FFE7 and working down in memory, let's start at >A040 and work our way up.

In my 3 line program example we enter line 1. The code goes starting at >A040 and after the code the line number table containing only line #1.

Enter line 2. Now the line number table has to be moved, the line 2 code added after the code for line #1 and line #2 is added to the LNT.

Enter line 3. Again the line number table must be moved, the code for line 3 added after the code for 1 and 2, then line #3 added to the LNT.

You can see there is no advantage compared to the normal way.

You can work out for yourself how it would go if the line number table was at >A040 followed by the code. That is even worse because there is all the code must be moved to add an entry to the LNT.

You could have the code at >A040 and the line number table at >FFE7. That would mean fewer bytes to move when entering code, but then how do you save the program with it split in two pieces?

 

Remember that the subject of this thread is execution speeds. None of the scenarios above would make any difference in execution speed.

Why would you put the Line Number Table at >FFE7? 

Why not put the Line number table at >A040 and first program line after it, that way could move EVERTHING for adding a line number in one small loop?

 

This is after all how XB moves from VDP programs to RAM programs. All in one loop.

 

You are just looking to argue as far as I can see. There is no real advantage to load programs from bottom to top.

Everyone loads programs from top down, well except XB and Basic.

Link to comment
Share on other sites

@senior_falcon is right. If you put the line number table at >A040 and first program line after it you would have to move both (part of) the line number table and the whole program every time you added a line. That would be a lot slower than it is. It's not a question of the number of loops but how many bytes you move if those loops.

  • Like 1
Link to comment
Share on other sites

20 minutes ago, Asmusr said:

@senior_falcon is right. If you put the line number table at >A040 and first program line after it you would have to move both (part of) the line number table and the whole program every time you added a line. That would be a lot slower than it is. It's not a question of the number of loops but how many bytes you move if those loops.

First off WRONG! 

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 is always much more efficient to move from Top to Bottom then it is from Bottom to Top.

 

Example does Forth only use bottom of stack or top of stack. Go ahead lie about that.

Does Forth start execution's at bottom of blocks or top?

 

I am pretty sure why Texas Instruments used Bottom up instead of Top down was >A000 to >A039 as assembly debugger was there and could not add more code.

This was for ASSMBLY like Editor Assembler but when XB came out they were forced into this.

Same with Basic as changing Video resolutions would mean expanding video tables would interfere with Basic programs and variables so pushed them up.

This could be solved like I did with RXB 2020 as now you can move VDP stack and XB programs to where you want with no issues.

  • Like 1
Link to comment
Share on other sites

31 minutes ago, Asmusr said:

@senior_falcon is right. If you put the line number table at >A040 and first program line after it you would have to move both (part of) the line number table and the whole program every time you added a line. That would be a lot slower than it is. It's not a question of the number of loops but how many bytes you move if those loops.

Why would you put the Line number table at other end of memory?

Other then to support Senior_Falcon argument that makes zero sense.

And as above I explained this would only have an effect on Edit Mode not Program mode ever.

Again jumping backwards all the time in XB to a lower address instead of a natural progress from top to bottom would always be more efficient.

 

Also I fixed this issue in RXB as you can move the VDP Stack where you want and XB programs to where you want before you even load.

It would be even better if XB did not run backwards from bottom to top.

 

RXB MEMORY MANAGER ROUTINES IN RXB 2020 - YouTube

Link to comment
Share on other sites

38 minutes ago, RXB said:

Example does Forth only use bottom of stack or top of stack. Go ahead lie about that.

Does Forth start execution's at bottom of blocks or top?

 

How Forth works is not really relevant to what XB is doing.

 

Forth usually pops numbers from the top of the stack (TOS), but both the data stack and return stack grow down in memory, so the TOS is at lower RAM than the bottom of the stack. 

 

Forth interpretation of blocks is from low RAM to high RAM within a block, but the next block could as easily be in lower RAM as higher RAM. Again, not relevant to XB logistics.

 

...lee

  • Like 2
Link to comment
Share on other sites

Reading this thread top-to-bottom is just as challenging as reading it from bottom-to-top.

 

 

Although not directly related to Extended BASIC, the Geneve BASIC interpreter seems to perform its line number operations in a similar fashion - provided I read the source code correctly - and with much larger programs similar line number performance seems to apply.  Given the explanation concerning the line number table handling, this makes sense (to me).

  • Like 2
Link to comment
Share on other sites

1 hour ago, Lee Stewart said:

 

How Forth works is not really relevant to what XB is doing.

 

Forth usually pops numbers from the top of the stack (TOS), but both the data stack and return stack grow down in memory, so the TOS is at lower RAM than the bottom of the stack. 

 

Forth interpretation of blocks is from low RAM to high RAM within a block, but the next block could as easily be in lower RAM as higher RAM. Again, not relevant to XB logistics.

 

...lee

So your saying bottom up is better, then how come you can not name other languages that do this?

Link to comment
Share on other sites

4 minutes ago, OLD CS1 said:

How many other BASIC implementations use a line number table?  CBM BASIC does not, so I suspect other 8-bit computer implementations from the same era, having been done by Microsoft, do not.

No one said line number tables are unique to XB or TI Basic. 

What is unique to TI Basic and XB is the programs goes bottom to top. That is also a odd ball thing.

Link to comment
Share on other sites

Are you guys just being obstinate on purpose to argue?

Not like I am the first person to point this out as kind of nuts in programming of how XB and TI Basic is backwards.

 

Also not one comment on how RXB 2020 has a memory manager to LOAD XB programs where ever you want in 24K?

Or to move the VDP Stack?

Can any other TI or Geneve XB do this?

Link to comment
Share on other sites

58 minutes ago, RXB said:

No one said line number tables are unique to XB or TI Basic. 

Being fair to myself, the question posed was one of generality, not as a question of uniqueness or implying any superiority of one over the other.

  • Like 2
Link to comment
Share on other sites

6 hours ago, RXB said:

Why would you put the Line number table at other end of memory?

 

From what I can understand here, it sounds like code at the bottom growing upwards, line number table at the top growing downwards. Correct? (or did I miss it)

This kind of division of data and code is not un-common.

C memory is organized like that on simple implementations like small C.  Code at the bottom, stack at the top and they grow towards each other.

It keeps radically different types of information out of each other's hair so to speak.

 

Since the line number table sounds like a linked list I don't think it matters very much which direction it grows in hardware does it ??

  • Like 1
Link to comment
Share on other sites

#1

On 11/12/2019 at 8:43 AM, HOME AUTOMATION said:

I decided, since I already knew my program would use a lot of subroutines, perhaps occupying as much or more space as the main program, I would write the main program starting on the lowest page, growing upward, then write the subroutines starting from the highest page and growing downward.

 

Link to comment
Share on other sites

27 minutes ago, TheBF said:

Since the line number table sounds like a linked list I don't think it matters very much which direction it grows in hardware does it ??

The TI BASIC/XB line number table is not a linked list.  It is simply a list of two words, first word with the line number and the second word with the VDP RAM address of the tokenized line.

 

CBM BASIC, and I suspect other Microsoft implementations, use the structure of next line number address (word,) line number (word,) then the null-terminated tokenized line.  All operations which affect execution position must scan through the program to find the target line.

 

The direction in which the table grows is not so much a big deal on its own, IMO.  The way TI implemented the BASIC store is that the line number table sits directly below the basic program store which also grows downward.  Thus, every time a new line is added or an existing line is edited to be longer, the entire line number table must be moved.

 

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.

 

At the same time, I see this as a little forward-thinking.  Consider if the ISR is playing a sound or moving sprites, interrupts must be turned off every time a program jumps to a new line.

  • Like 1
Link to comment
Share on other sites

(Edit) Rich, here are a couple of points to consider:

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.

2 - I have made almost 70 trips around the sun, and have learned that when there is something I don't understand, my first reaction is not to assume it was created by someone who is a moron, an idiot, a fool, is insane, or doesn't have a brain cell. Instead, I wonder what I am missing and if there might actually be a good reason for it being done the way it was.  Here are two possibilities:

   Remember that XB runs in VDP ram when there is no memory expansion. One possible reason for growing the XB program downward from the highest memory location could be that it just plain works better that way when running in VDP ram. There is stuff going on at v0958 that grows upward in memory and this might keep the program from colliding with that.

   When editing an XB program every entry involves moving blocks of memory to make room for the new line. As XB is written you move bytes down when you add program lines and this is slightly more efficient than moving bytes up to add program lines.

         Move >100 bytes down from >EF10 to >EF00              Move >100 bytes up from >EF00 to EF10

         LI R1,>EF10                                                              LI R1,>F010                   

         LI R2,>EF00                                                              LI R2,>F000

         LI R3,>0100                                                              LI R3,>0100

LOOP MOVB *R1+,*R2+                                             LOOP MOVB *R1,*R2

         DEC R3                                                                     DEC R1

         JNE LOOP                                                                  DEC R2

                                                                                         DEC R3

                                                                                         JNE LOOP

3 - When Rasmus or Tursi says something don't argue. Consider anything they say to be as authoritative as Moses coming down from Mount Sinai with the 10 commandments.

4 - Calling people liars is not very polite and might lead to hard feelings. This could alienate the very people you want to help with your project, which is probably not the outcome you hoped for.

Edited by senior_falcon
  • Like 5
Link to comment
Share on other sites

23 minutes ago, senior_falcon said:

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.

That was my misunderstanding, then, as I recalled it said the table was scanned downward.  Which would not make sense given the results with line number tests.  The code is tl;dr for me right now.  Is auto-increment used throughout the search or just to pull the line number and address?

 

28 minutes ago, senior_falcon said:

3 - When Rasmus or Tursi says something don't argue. Consider anything they say to be as authoritative as Moses coming down from Mount Sinai with the 10 commandments.

I would add @mizapf to that list.  As an aside, when I was a kid I thought he came down from Mount Cyanide.

 

29 minutes ago, senior_falcon said:

4 - Calling people liars is not very polite and might lead to hard feelings. This could alienate the very people you want to help with your project, which is probably not the outcome you hoped for.

People tend to take things personally and make personal attacks, both unnecessarily.  It is a real quick way to shit up a thread.  I do not appreciate attacks in my threads and would appreciate if people would take a second and clean up their posts, preferably before posting but after the fact if need-be.  This is not Facebook or Twitter -- we have (some) class around here.

  • Like 3
  • Haha 2
Link to comment
Share on other sites

...speak for yourself.;)

 

Windows' installer runs from the top of hard drive free space and installs Windows to the bottom.:thumbsup:

 

When LOADERS load a program, the REF/DEF table grows downward.:thumbsdown:

 

If you enter an elevator in a tall building ...and the brakes suddenly and mysteriously happen to fail:evil:⚙️... you'll fall upward until conceivably crashing into the penthouse!(trust me on this one)⚖️

 

But, you'll always meet the same people on the way up as you did on the way down.:grin:

  • Haha 2
Link to comment
Share on other sites

And you wonder why I dropped off the TI99/4A map for years... from 2001 to 2009

 

Go back and look I never once called anyone a  liar! Yet you post this?

 

4 - Calling people liars is not very polite and might lead to hard feelings. This could alienate the very people you want to help with your project, which is probably not the outcome you hoped for.

 

 

 

 

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