Temporary Variables, John Wayne, and Keanu f**king reeves

[Retrospect]

23 hours ago, RXB said:

Lastly any SUB programs use TEMPORARY variables

what is meant by Temporary variables in sub programs?  

[RXB]

2 hours ago, Retrospect said:

what is meant by Temporary variables in sub programs?  

Say you use SUB TEST(X,Y,Z$)

In XB the normal variables are passed to the subprogram and a temporary variable is set up with a temporary storage.

As these variables are only available to that sub-program memory this is why you cannot show them outside the SUB routine.

Also if a Garbage Collection is executed that X, Y and Z$ will have to be recalculated again on next call of SUB TEST(X,Y,Z$)

 

If you fire up Classic99 and the Debugger you can see this happening in VDP memory as those temp variables show up and are erased during a Garbage Collection.

Of course you can see this best with no 32K as it becomes much more easy to see.

[Retrospect]

1 minute ago, RXB said:

Say you use SUB TEST(X,Y,Z$)

ahh, right okay.  Believe it or not I've never used that in my code, I literally just Gosub to stuff instead.  

[+OLD CS1]

8 hours ago, RXB said:

Also if a Garbage Collection is executed that X, Y and Z$ will have to be recalculated again on next call of SUB TEST(X,Y,Z$)

Interesting.  I did not know variables were volatile in this way.

[senior_falcon]

8 hours ago, RXB said:

Say you use SUB TEST(X,Y,Z$)

In XB the normal variables are passed to the subprogram and a temporary variable is set up with a temporary storage.

As these variables are only available to that sub-program memory this is why you cannot show them outside the SUB routine.

Also if a Garbage Collection is executed that X, Y and Z$ will have to be recalculated again on next call of SUB TEST(X,Y,Z$)

 

If you fire up Classic99 and the Debugger you can see this happening in VDP memory as those temp variables show up and are erased during a Garbage Collection.

Of course you can see this best with no 32K as it becomes much more easy to see.

The idea of "temporary variables" is simply not accurate, unless you are referring to the way XB handles strings

 

Consider these programs:

10 X=64
20 CALL TEST(X)
30 GOTO 30
100 SUB TEST(Y)
110 Y=99
120 !GOTO 120
130 SUBEND

When you run the program X is initialized as 64. CALL TEST(X) then passes the value of 64 to the variable Y in the subprogram. Y is then set to 99 and control returns to the calling XB program setting X to 99, which is the value of Y in the subprogram. Then line 30 is an endless loop.

Fctn 4 to break the program, then PRINT X,Y and 99   0 are printed, which you would expect.

Uncomment line 120 to make the endless loop happen in the sub.

Fctn 4 to break the program, then PRINT X,Y and 0   99 are printed. There is no X in the program, so 0 is printed and Y was set to 99 in the sub.

 

Next program. First do a cold reset, then:

10 X=X+1
20 CALL TEST(X)
30 GOTO 10
100 SUB TEST(Y)
110 Y=Y*1.23
120 SUBEND

Here the value X has 1 added to it. It then is passed to the subprogram TEST, which uses it which uses it as the variable Y. In the sub, Y is multiplied by 1.23 and then control returns to the calling XB program. The value for Y is returned as X. 1 is added to X, then TEST is called again. This goes on forever.

While it is running, get in the debugger and look at cpu starting at >FF00. You will see 8 consecutive bytes at >FF92. This is the floating point number that represents both X in the main program, and Y in the subprogram TEST. This is important, so I will repeat: X points to this value, and Y in the subprogram also points to the same value.

Look at the page of VDP ram starting at >3700. There is nothing going on there, hence there will never be a garbage collection for this program.

 

Next program. What about strings?  First do a cold reset, then:

10 A$="HELLO WORLD"
20 CALL TEST(A$)
30 GOTO 20
100 SUB TEST(B$)
110 SUBEND

This sets A$ to "HELLO WORLD". This is passed to the subprogram TEST as the string variable B$. The subprogram ends, control is passed back to the calling XB program, which then goes to line 20 to CALL TEST again in an endless loop.

With the program running, here is the VDP ram from v3700 to v37D7.

There is only one "HELLO WORLD", located at v37A4

Just before the A$ is the pointer to the string, which is >37A4

Just before the B$ (remember that B$ is in the subprogram) the pointer is >37D4, and at >37D4 is the pointer to the string which is at >37A4.

So here again A$ and B$ point to the same string.

If you ran this program you would see that, once again, nothing is happening  in the VDP stack. You can see this in the picture above with 16 zeros. So there will never be a garbage collection for this program.

 

Next program. What about those temporary variables and garbage collection? As usual, do a cold reset, then:

10 A$="HELLO WORLD"::GOTO 10

Set the debugger to look at VDP starting at v3700.  Run the program and you will quickly see the screen filled with "HELLO WORLD." When the VDP stack is filled up to about v09A4 the garbage collection is triggered.

At CPU ram >831A is the pointer to first free address in VDP ram. As the stack fills up you will see this number getting smaller until it does the garbage collection which resets the stack pointer. You may notice that the vdp ram is not cleared by the garbage collection. There is no need because XB knows where to find A$ (or B$ in the sub)

 

This is perfectly normal XB behavior when handling strings. Temporary strings are used when you PRINT X, and they go on the stack as well. Any time you manipulate a string in any way it will go on the stack, and using strings is what leads to the garbage collection. Handling strings in a subprogram does not cause garbage collection to occur more frequently than if they were handled in the main XB program.

 

Also if a Garbage Collection is executed that X, Y and Z$ will have to be recalculated again on next call of SUB TEST(X,Y,Z$)

There is no way X and Y have to be recalculated after a garbage collection. Z$ will be moved, or put on the stack, in the normal XB fashion.

 

 

 

 

 

 

 

[RXB]

41 minutes ago, senior_falcon said:

The idea of "temporary variables" is simply not accurate, unless you are referring to the way XB handles strings

 

Consider these programs:

10 X=64
20 CALL TEST(X)
30 GOTO 30
100 SUB TEST(Y)
110 Y=99
120 !GOTO 120
130 SUBEND

When you run the program X is initialized as 64. CALL TEST(X) then passes the value of 64 to the variable Y in the subprogram. Y is then set to 99 and control returns to the calling XB program setting X to 99, which is the value of Y in the subprogram. Then line 30 is an endless loop.

Fctn 4 to break the program, then PRINT X,Y and 99   0 are printed, which you would expect.

Uncomment line 120 to make the endless loop happen in the sub.

Fctn 4 to break the program, then PRINT X,Y and 0   99 are printed. There is no X in the program, so 0 is printed and Y was set to 99 in the sub.

 

Next program. First do a cold reset, then:

10 X=X+1
20 CALL TEST(X)
30 GOTO 10
100 SUB TEST(Y)
110 Y=Y*1.23
120 SUBEND

Here the value X has 1 added to it. It then is passed to the subprogram TEST, which uses it which uses it as the variable Y. In the sub, Y is multiplied by 1.23 and then control returns to the calling XB program. The value for Y is returned as X. 1 is added to X, then TEST is called again. This goes on forever.

While it is running, get in the debugger and look at cpu starting at >FF00. You will see 8 consecutive bytes at >FF92. This is the floating point number that represents both X in the main program, and Y in the subprogram TEST. This is important, so I will repeat: X points to this value, and Y in the subprogram also points to the same value.

Look at the page of VDP ram starting at >3700. There is nothing going on there, hence there will never be a garbage collection for this program.

 

Next program. What about strings?  First do a cold reset, then:

10 A$="HELLO WORLD"
20 CALL TEST(A$)
30 GOTO 20
100 SUB TEST(B$)
110 SUBEND

This sets A$ to "HELLO WORLD". This is passed to the subprogram TEST as the string variable B$. The subprogram ends, control is passed back to the calling XB program, which then goes to line 20 to CALL TEST again in an endless loop.

With the program running, here is the VDP ram from v3700 to v37D7.

There is only one "HELLO WORLD", located at v37A4

Just before the A$ is the pointer to the string, which is >37A4

Just before the B$ (remember that B$ is in the subprogram) the pointer is >37D4, and at >37D4 is the pointer to the string which is at >37A4.

So here again A$ and B$ point to the same string.

If you ran this program you would see that, once again, nothing is happening  in the VDP stack. You can see this in the picture above with 16 zeros. So there will never be a garbage collection for this program.

 

Next program. What about those temporary variables and garbage collection? As usual, do a cold reset, then:

10 A$="HELLO WORLD"::GOTO 10

Set the debugger to look at VDP starting at v3700.  Run the program and you will quickly see the screen filled with "HELLO WORLD." When the VDP stack is filled up to about v09A4 the garbage collection is triggered.

At CPU ram >831A is the pointer to first free address in VDP ram. As the stack fills up you will see this number getting smaller until it does the garbage collection which resets the stack pointer. You may notice that the vdp ram is not cleared by the garbage collection. There is no need because XB knows where to find A$ (or B$ in the sub)

 

This is perfectly normal XB behavior when handling strings. Temporary strings are used when you PRINT X, and they go on the stack as well. Any time you manipulate a string in any way it will go on the stack, and using strings is what leads to the garbage collection. Handling strings in a subprogram does not cause garbage collection to occur more frequently than if they were handled in the main XB program.

 

Also if a Garbage Collection is executed that X, Y and Z$ will have to be recalculated again on next call of SUB TEST(X,Y,Z$)

There is no way X and Y have to be recalculated after a garbage collection. Z$ will be moved, or put on the stack, in the normal XB fashion.

 

 

 

 

 

 

 

First off unless the memory is full it does not do a recovery of memory with Garbage Collection.

It may look and if there is plenty left it just ignores the command.

In RXB many of my routines use COMPCT (Garbage Collection):

 0694            ************************************************************
  0695            * ASSGNV, callable from GPL or 9900 code, to assign a value 
  0696            * to a symbol (strings and numerics) . If numeric, the  
  0697            * 8 byte descriptor is in the FAC. The descriptor block   
  0698            * (8 bytes) for the destination variable is on the stack.   
  0699            * There are two types of descriptor entries which are   
  0700            * created by SMB in preparation for ASSGNV, one for   
  0701            * numerics and one for strings.   
  0702            *                     NUMERIC   
  0703            * +-------------------------------------------------------+ 
  0704            * |S.T. ptr | 00 |       |Value ptr |                     | 
  0705            * +-------------------------------------------------------+ 
  0706            *                     STRING  
  0707            * +-------------------------------------------------------+ 
  0708            * |Value ptr| 65 |       |String ptr|String length        | 
  0709            * +-------------------------------------------------------+ 
  0710            *   
  0711            * CRITICAL NOTE: Becuase of the BL @POPSTK below, if a  
  0712            * string entry is popped and a garbage collection has taken 
  0713            * place while the entry was pushed on the stack, and the  
  0714            * entry was a permanent string the pointer in FAC4 and FAC5 
  0715            * will be messed up. A BL @VPOP would have taken care of  
  0716            * the problem but would have taken a lot of extra code.   
  0717            * Therefore, at ASSG50-ASSG54 it is assumed that the  
  0718            * previous value assigned to the destination variable has   
  0719            * been moved and the pointer must be reset by going back to 
  0720            * the symbol table and getting the correct value pointer.   
  0721            ************************************************************

Now MEMCHG is another routine I often use in RXB routines:

2482            ************************************************************
  2483            *                 MEMORY CHECK ROUTINE  
  2484            * It checks to see if there is enough room to insert a  
  2485            * symbol table entry or a P.A.B. into the VDP between the   
  2486            * static symbol table/PAB area and the dymamic string area. 
  2487            * If there is not it attempts to move the string space down 
  2488            * (to  lower address) and then insert the needed area   
  2489            * between the two. NOTE: it may invoke COMPCT to do a   
  2490            * garbage collection. If there is not enough space after  
  2491            * COMPCT then issues *MEMORY FULL* message.   
  2492            *   
  2493            * INPUT:  # of bytes needed in FAC, FAC+1   
  2494            * USES:   R0, R12 as temporaries as well as R0 - R6 when  
  2495            *         invoking COMPCT   
  2496            ************************************************************

And lastly I use GETSTR in RXB:

  2558            ************************************************************
  2559            * GETSTR - Checks to see if there is enough space in the  
  2560            *          string area to allocate a string, if there is it 
  2561            *          allocates it. If there is not it does a garbage  
  2562            *          collection and once again checks to see if there 

 99/4 ASSEMBLER
STRINGS                                                      PAGE 0059
  2563            *          is enough room. If so it allocates it, if not it 
  2564            *          issues a *MEMORY FULL* message.  
  2565            *   
  2566            * INPUT :  # of bytes needed in @BYTE   
  2567            * OUTPUT:  Pointer to new string in @SREF   
  2568            *          Both length bytes in place & zeroed Breakpointer 
  2569            *          @STREND points 1st free byte(new)  
  2570            *   
  2571            * USES  :  R0 - R6 Temporaries  
  2572            *   
  2573            * Note  :  COMPCT allows a buffer zone of 8 stack entries   
  2574            *          above what is there when COMPCT is called. This  
  2575            *          should allow enough space to avoid a collision   
  2576            *          between the string space and the stack. If   
  2577            *          garbage begins to appear in the string space   
  2578            *          that can't be accounted for, the buffer zone   
  2579            *          will be increased.   
  2580            ************************************************************

These are all XML routines in ROM 1 of XB.

  2615            ************************************************************
  2616            * COMPCT - Is the string garbage collection routine. It can 
  2617            *          be invoked by GETSTR or MEMCHK. It copies all  
  2618            *          used strings to the top of the string space  
  2619            *          suppressing out all of the unused strings  
  2620            *    INPUT : None   
  2621            *    OUTPUT: UPDATED @STRSP AND @STREND   
  2622            *    USES  : R0-R6 AS TEMPORARIES   
  2623            ************************************************************

As CONSOLE only uses only VDP vs 32K use you get different results after all Numeric Variables only reside in VDP only in Console only.

I do happen to know the internal structure of how XB works and can post the source code.

[RXB]

49 minutes ago, senior_falcon said:

The idea of "temporary variables" is simply not accurate, unless you are referring to the way XB handles strings

 

Consider these programs:

10 X=64
20 CALL TEST(X)
30 GOTO 30
100 SUB TEST(Y)
110 Y=99
120 !GOTO 120
130 SUBEND

When you run the program X is initialized as 64. CALL TEST(X) then passes the value of 64 to the variable Y in the subprogram. Y is then set to 99 and control returns to the calling XB program setting X to 99, which is the value of Y in the subprogram. Then line 30 is an endless loop.

Fctn 4 to break the program, then PRINT X,Y and 99   0 are printed, which you would expect.

Uncomment line 120 to make the endless loop happen in the sub.

Fctn 4 to break the program, then PRINT X,Y and 0   99 are printed. There is no X in the program, so 0 is printed and Y was set to 99 in the sub.

 

Next program. First do a cold reset, then:

10 X=X+1
20 CALL TEST(X)
30 GOTO 10
100 SUB TEST(Y)
110 Y=Y*1.23
120 SUBEND

Here the value X has 1 added to it. It then is passed to the subprogram TEST, which uses it which uses it as the variable Y. In the sub, Y is multiplied by 1.23 and then control returns to the calling XB program. The value for Y is returned as X. 1 is added to X, then TEST is called again. This goes on forever.

While it is running, get in the debugger and look at cpu starting at >FF00. You will see 8 consecutive bytes at >FF92. This is the floating point number that represents both X in the main program, and Y in the subprogram TEST. This is important, so I will repeat: X points to this value, and Y in the subprogram also points to the same value.

Look at the page of VDP ram starting at >3700. There is nothing going on there, hence there will never be a garbage collection for this program.

 

Next program. What about strings?  First do a cold reset, then:

10 A$="HELLO WORLD"
20 CALL TEST(A$)
30 GOTO 20
100 SUB TEST(B$)
110 SUBEND

This sets A$ to "HELLO WORLD". This is passed to the subprogram TEST as the string variable B$. The subprogram ends, control is passed back to the calling XB program, which then goes to line 20 to CALL TEST again in an endless loop.

With the program running, here is the VDP ram from v3700 to v37D7.

There is only one "HELLO WORLD", located at v37A4

Just before the A$ is the pointer to the string, which is >37A4

Just before the B$ (remember that B$ is in the subprogram) the pointer is >37D4, and at >37D4 is the pointer to the string which is at >37A4.

So here again A$ and B$ point to the same string.

If you ran this program you would see that, once again, nothing is happening  in the VDP stack. You can see this in the picture above with 16 zeros. So there will never be a garbage collection for this program.

 

Next program. What about those temporary variables and garbage collection? As usual, do a cold reset, then:

10 A$="HELLO WORLD"::GOTO 10

Set the debugger to look at VDP starting at v3700.  Run the program and you will quickly see the screen filled with "HELLO WORLD." When the VDP stack is filled up to about v09A4 the garbage collection is triggered.

At CPU ram >831A is the pointer to first free address in VDP ram. As the stack fills up you will see this number getting smaller until it does the garbage collection which resets the stack pointer. You may notice that the vdp ram is not cleared by the garbage collection. There is no need because XB knows where to find A$ (or B$ in the sub)

 

This is perfectly normal XB behavior when handling strings. Temporary strings are used when you PRINT X, and they go on the stack as well. Any time you manipulate a string in any way it will go on the stack, and using strings is what leads to the garbage collection. Handling strings in a subprogram does not cause garbage collection to occur more frequently than if they were handled in the main XB program.

 

Also if a Garbage Collection is executed that X, Y and Z$ will have to be recalculated again on next call of SUB TEST(X,Y,Z$)

There is no way X and Y have to be recalculated after a garbage collection. Z$ will be moved, or put on the stack, in the normal XB fashion.

 

 

 

 

 

 

 

Maybe I should explain a Temporary Variable like: INT(2.5*7)+R would be a Temporary variable to save the value +R

As INT(2.5*7) is a 8 byte Floating Point value and R is also a 8 byte Floating Point value but only the R is permanent as a variable, the INT(2.5*7) is a temporary one.

 

Extended Basic Manual page 181 fully explains what I am saying having to do with SUB 

[sometimes99er]

1 hour ago, senior_falcon said:

Any time you manipulate a string in any way it will go on the stack, and using strings is what leads to the garbage collection.

Apart from strings, what else leads to a garbage collection ? BITD when buying XB, I quickly discovered a pause in my upcoming games. I made a demo of a sprite travelling across the screen, and after some minutes, there were a noticeable hiccup - a pause of perhaps more than a second. The store could see the problem, and it was reported through whatever channels. About two weeks later, I was told, that it was normal behavior. How nice. - At the time, 1982, there weren't that much information about the inner workings, but I think I got some photocopies mentioning the garbage collection. I figured machine code would get around that, and got the Mini Memory. Also got a standalone 32K Memory Expansion. The audience I could release games for was however immensely limited (in Denmark at least), so I got other home computers, that all, from the word go, had peek, poke and access to the speed of machine code.

Edited March 9, 2023 by sometimes99er

[senior_falcon]

7 hours ago, RXB said:

Maybe I should explain a Temporary Variable like: INT(2.5*7)+R would be a Temporary variable to save the value +R

As INT(2.5*7) is a 8 byte Floating Point value and R is also a 8 byte Floating Point value but only the R is permanent as a variable, the INT(2.5*7) is a temporary one.

 

Extended Basic Manual page 181 fully explains what I am saying having to do with SUB 

Poor choice of words. Consider the line 10 X=INT(2.5*7)+R

Here X is a variable and INT(2.5*7)+R is a numeric expression, not a variable.

 

You have made several statements that i believe are incorrect:

 

"Lastly any SUB programs use TEMPORARY variables thus will trigger a garbage collection more often than normal variables as they are not TEMPORARY." This statement makes no sense.

"In XB the normal variables are passed to the subprogram and a temporary variable is set up with a temporary storage." As shown earlier, the variables in a subprogram are as permanent as a variable in the main part of the program.

"Also if a Garbage Collection is executed that X, Y and Z$ will have to be recalculated again on next call of SUB TEST(X,Y,Z$)"  As I mentioned earlier, there is no way that X and Y would have to be recalculated.

Of course, if you do CALL TEST(X+3,Y-2,Z$&A$) then all those expressions would have to be evaluated, but that has nothing to do with a garbage collection.

 

I have looked carefully at page 181 and nowhere do I see anything that would lead me (or anyone else) to the opinions stated above, especially in regards to garbage collection.

[RXB]

4 hours ago, senior_falcon said:

Poor choice of words. Consider the line 10 X=INT(2.5*7)+R

Here X is a variable and INT(2.5*7)+R is a numeric expression, not a variable.

 

You have made several statements that i believe are incorrect:

 

"Lastly any SUB programs use TEMPORARY variables thus will trigger a garbage collection more often than normal variables as they are not TEMPORARY." This statement makes no sense.

"In XB the normal variables are passed to the subprogram and a temporary variable is set up with a temporary storage." As shown earlier, the variables in a subprogram are as permanent as a variable in the main part of the program.

"Also if a Garbage Collection is executed that X, Y and Z$ will have to be recalculated again on next call of SUB TEST(X,Y,Z$)"  As I mentioned earlier, there is no way that X and Y would have to be recalculated.

Of course, if you do CALL TEST(X+3,Y-2,Z$&A$) then all those expressions would have to be evaluated, but that has nothing to do with a garbage collection.

 

I have looked carefully at page 181 and nowhere do I see anything that would lead me (or anyone else) to the opinions stated above, especially in regards to garbage collection.

Please show me the source code of this. I require proof of YOUR OPINION.

It is not like I have not shared all the XB source for 30 years now.

[senior_falcon]

Well, you got me there. It is just my OPINION. Of course, my OPINION is based on my observations and I am just reporting what I see. It is also my opinion that when an apple falls from a tree it hits the ground instead of floating up into the clouds.

     To recap: you made the claim that when performing a user subprogram there was additional activity in the vdp involving temporary variables and the like that would trigger more frequent garbage collections, which would slow down the XB program.

     I believe that is not the case and that garbage collections would be no more frequent when using user subprograms than would happen in normal XB. (i.e. when not using user subprograms)

     In one of my earlier posts there were 4 short XB programs that show why I believe this to be true. I took quite a bit of time in thinking about these programs and how to explain what they did and why.

     I  believe (just my OPINION) that if you actually were to run those programs, observe what happens, and take some time to reflect on the results, that you would come to share my OPINION.

     I also believe (again just my OPINION) that you have not done this and will not do this. After all, you might actually learn something, and we can't have that, can we?

[RXB]

I have no doubt to your skills or talents, just give me some credit too. 

Is that to much to ask?

[senior_falcon]

1 hour ago, RXB said:

I have no doubt to your skills or talents, just give me some credit too. 

Is that to much to ask?

I would be happy to give you some credit. But you have to earn it.

You have made a statement that I feel is incorrect based on my tests. I have posted 4 programs that explain why I believe what I believe. There are three ways you can earn the credit you want:

1 - You actually take the time to run the programs I posted and take a few minutes to reflect on why they behave the way they do. At that point you may decide that your earlier statements were incorrect and that garbage collections are actually not more frequent in subprograms

2 - You take the time to run the programs I posted, but see that I have come to the wrong conclusions. You post corrections that help me see what it is in subprograms that causes all this extra activity is in the VDP.

3 - You come up with an XB program using subprograms that demonstrates the extra vdp activity that triggers more frequent garbage collections.

[RXB]

19 minutes ago, senior_falcon said:

I would be happy to give you some credit. But you have to earn it.

You have made a statement that I feel is incorrect based on my tests. I have posted 4 programs that explain why I believe what I believe. There are three ways you can earn the credit you want:

1 - You actually take the time to run the programs I posted and take a few minutes to reflect on why they behave the way they do. At that point you may decide that your earlier statements were incorrect and that garbage collections are actually not more frequent in subprograms

2 - You take the time to run the programs I posted, but see that I have come to the wrong conclusions. You post corrections that help me see what it is in subprograms that causes all this extra activity is in the VDP.

3 - You come up with an XB program using subprograms that demonstrates the extra vdp activity that triggers more frequent garbage collections.

Run them from Console only and tell me I am wrong.

Can you show me the code that triggers a Garbage Collection? 

And again, show me your SOURCE CODE in XB GPL/ROM Assembly to prove it.

Your opinion is based on limited testing not the code that runs XB, arrogance abounds.

[+InsaneMultitasker]

17 hours ago, senior_falcon said:

Handling strings in a subprogram does not cause garbage collection to occur more frequently than if they were handled in the main XB program.

Is there any difference in garbage collection frequency when passing information using the extra set of parenthesis to isolate a value so it isn't "passed back" to the caller, e.g., CALL MYSUB((C$))?   Anecdotally, I don't recall any extra garbage collection due to subprogram usage.  My BBS software has quite a bit of string and variable subprogram passing; I would have noticed this very quickly as my focus was on the user experience.

[jrhodes]

1 hour ago, RXB said:

arrogance abounds

I'd like to nominate the thread title be changed to the above ^

Also a new subforum should be created: "The boxing ring". Move any disruptive content like this into the new subforum and let them duke it out there.

[+OLD CS1]

30 minutes ago, jrhodes said:

I'd like to nominate the thread title be changed to the above ^

Also a new subforum should be created: "The boxing ring". Move any disruptive content like this into the new subforum and let them duke it out there.

No need to antagonize.

[+InsaneMultitasker]

On 3/8/2023 at 9:51 AM, Retrospect said:

what is meant by Temporary variables in sub programs?  

The XB manual does a fairly good job of explaining subprogram variable usage.  I don't think I have ever heard of the variables described as "temporary" but I can see that the question has generated some interesting responses.  I always thought of the variables that are passed as one or more "conduits" between the main program and the subprogram, and anytime I wanted to preserve what was passed to the subprogram, I assigned to a "local" variable something like this 1000 SUB A(C$):: A$=C$:: <other statements> ::SUBEND.  If I then used CALL A(TEST$) the value of TEST$ wouldn't be changed by the subprogram, because I used A$ to manipulate the value inside the subprogram.  Unless, of course, I wanted to change the value for some reason.  Pretty neat stuff.   (Edit: typed the wrong variable!)

 

Spoiler

Extended BASIC manual :

 

All variables used in a subprogram other than those in parameter-list are local to that
subprogram. so you may use the same variable names that are used in the main program or
in other subprograms, and alter their values, without having any effect on other variables.
Likewise, the values of variables in the main program or other subprograms have no effect on
the values of the variables in the subprogram. (However, DATA statements are available to
subprograms.)

Communicating values to and from the main program is done with the optional parameterlist.
The parameters need not have the same names as in the calling statement, but they
must be of the same data type (numeric or string), and in the same order as the items in the
CALL. If simple variables passed to subprograms have their values changed in the
subprogram, the values of the variables in the main program are also changed. An array
element such as A(1) in the parameter list of the calling statement is also changed in value in
the main program when control is returned to the main program.

A value that is given in the calling statement as an expression is passed as a value only and
changes in the value in the subprogram do not change values in the main program. Entire
arrays are passed by reference, so changes in elements in the subprogram also change the
values of the elements of the array in the main program. Arrays are indicated by following the
parameter name with parentheses. If the array has more than one dimension, a comma must
be placed inside the parentheses for each additional dimension.

If you wish, you may pass values only for simple variables by enclosing them in parentheses.
Then the value can be used in the subprogram, but it is not changed in the return to the main
program. For example, CALL SPRG1((A)) passes the value of A to a subprogram that starts
SUB SPRG1(X), and allows that value to be used in X, but does not change the value of A in
the main program if the subprogram changes the value of X.

If a subprogram is called more than once, any local variables used in the subprogram retain
those values from one call to the next.

 

[Retrospect]

17 minutes ago, InsaneMultitasker said:

I don't think I have ever heard of the variables described as "temporary"

The only time I ever read the word "Temporary" in any program, was when I was attempting to read the Tombstone City source code , written by John Plaster.  There was I think four usages of the word Temporary in there.  And I still haven't the foggiest what was meant by that.    I've also never heard of Temporary variables in sub-programs, but, as I have never actually used a sub-program I wouldn't know either way.  I use subroutines, Gosubs, that's all.  I see no point in the two existing side by side.  A subprogram to me is a subroutine with a label.  This is of course, possibly due to my misunderstanding of the variables in subprograms.  That manual hasn't helped me, I'm a slow learner, I'm afraid! 

[senior_falcon]

2 hours ago, RXB said:

Run them from Console only and tell me I am wrong.

Can you show me the code that triggers a Garbage Collection? 

And again, show me your SOURCE CODE in XB GPL/ROM Assembly to prove it.

Your opinion is based on limited testing not the code that runs XB, arrogance abounds.

     I must be going senile. I learned years ago that any "conversation" with Rich always wound up in an endless loop that could never go anywhere. But somehow I managed to forget that.

     I have placed a hammer next to each of my computers and instructed my wife and colleagues to monitor me closely. If they ever see me replying to a post by RXB, they are to take the hammer and break all of my fingers.

     Desperate times call for desperate measures.

Edited March 9, 2023 by senior_falcon

[+InsaneMultitasker]

31 minutes ago, Retrospect said:

I use subroutines, Gosubs, that's all.  I see no point in the two existing side by side.  A subprogram to me is a subroutine with a label. 

I use subprograms to keep certain things separate from the main program, so there is little chance of me messing things up with a re-used variable or line of code. I also like using subprograms if I plan to do the same thing in another program.  It is quite easy to "copy and paste" a subprogram into other programs, without worrying if the variables and lines are re-used.  MERGE was a great friend back in the day.  Now, with all the advanced editing tools, maybe subs aren't as necessary but I still like them    Also, they are easy to test and play with if so inclined, because they work just like many other subs you are used to - CALL CHAR, CALL SOUND, etc. except that you program them yourself.

[Retrospect]

3 minutes ago, InsaneMultitasker said:

little chance of me messing things up with a re-used variable or line of code.

That is a fair point. 

[HOME AUTOMATION]

1 hour ago, senior_falcon said:

(Link)👆

[RXB]

9 hours ago, senior_falcon said:

     I must be going senile. I learned years ago that any "conversation" with Rich always wound up in an endless loop that could never go anywhere. But somehow I managed to forget that.

     I have placed a hammer next to each of my computers and instructed my wife and colleagues to monitor me closely. If they ever see me replying to a post by RXB, they are to take the hammer and break all of my fingers.

     Desperate times call for desperate measures.

When you are losing a argument just go for the personal attack on them. To hell with logic right?

[GDMike]

🍿,  🪑