Retrospect Posted July 23, 2021 Share Posted July 23, 2021 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. Quote Link to comment Share on other sites More sharing options...
GDMike Posted July 23, 2021 Share Posted July 23, 2021 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. ? Quote Link to comment Share on other sites More sharing options...
senior_falcon Posted July 23, 2021 Share Posted July 23, 2021 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. 2 Quote Link to comment Share on other sites More sharing options...
+OLD CS1 Posted July 23, 2021 Author Share Posted July 23, 2021 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. 3 Quote Link to comment Share on other sites More sharing options...
GDMike Posted July 23, 2021 Share Posted July 23, 2021 Clean up on isle, uh.., atariage please. Quote Link to comment Share on other sites More sharing options...
HOME AUTOMATION Posted July 23, 2021 Share Posted July 23, 2021 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... ...Time to install glass floors in all elevators! 1 1 Quote Link to comment Share on other sites More sharing options...
RXB Posted July 23, 2021 Share Posted July 23, 2021 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. 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. Quote Link to comment Share on other sites More sharing options...
senior_falcon Posted July 23, 2021 Share Posted July 23, 2021 Rich, you do realize that Top-Down vs Bottom-Up programming has exactly nothing to do with how the code is arranged in memory? 3 Quote Link to comment Share on other sites More sharing options...
+OLD CS1 Posted July 23, 2021 Author Share Posted July 23, 2021 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. 1 Quote Link to comment Share on other sites More sharing options...
RXB Posted July 24, 2021 Share Posted July 24, 2021 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! Quote Link to comment Share on other sites More sharing options...
+OLD CS1 Posted July 24, 2021 Author Share Posted July 24, 2021 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. 1 Quote Link to comment Share on other sites More sharing options...
RXB Posted July 24, 2021 Share Posted July 24, 2021 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. Quote Link to comment Share on other sites More sharing options...
+OLD CS1 Posted July 24, 2021 Author Share Posted July 24, 2021 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. 2 Quote Link to comment Share on other sites More sharing options...
+OLD CS1 Posted July 24, 2021 Author Share Posted July 24, 2021 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. 2 Quote Link to comment Share on other sites More sharing options...
senior_falcon Posted July 24, 2021 Share Posted July 24, 2021 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. 1 Quote Link to comment Share on other sites More sharing options...
RXB Posted July 24, 2021 Share Posted July 24, 2021 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. Quote Link to comment Share on other sites More sharing options...
+OLD CS1 Posted July 24, 2021 Author Share Posted July 24, 2021 Consensus 2 Quote Link to comment Share on other sites More sharing options...
RXB Posted July 24, 2021 Share Posted July 24, 2021 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. Quote Link to comment Share on other sites More sharing options...
senior_falcon Posted July 24, 2021 Share Posted July 24, 2021 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. 1 Quote Link to comment Share on other sites More sharing options...
Retrospect Posted July 24, 2021 Share Posted July 24, 2021 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. 1 Quote Link to comment Share on other sites More sharing options...
GDMike Posted July 24, 2021 Share Posted July 24, 2021 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. Quote Link to comment Share on other sites More sharing options...
+OLD CS1 Posted July 24, 2021 Author Share Posted July 24, 2021 4 Quote Link to comment Share on other sites More sharing options...
senior_falcon Posted July 25, 2021 Share Posted July 25, 2021 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. 5 Quote Link to comment Share on other sites More sharing options...
SteveB Posted July 25, 2021 Share Posted July 25, 2021 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... Quote Link to comment Share on other sites More sharing options...
+OLD CS1 Posted July 25, 2021 Author Share Posted July 25, 2021 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. 1 Quote Link to comment Share on other sites More sharing options...
Recommended Posts
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.