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

[apersson850]

11 hours ago, RXB said:

I am curious how you know so many intimate details of XB internal structure without a single line of code for how it works?

Because I know computers.

2 hours ago, RXB said:

If you call the Variables in that routine you have to use the same SUB TEST(X,Y,Z$) or you can only get those values when inside that SUB.

If you call it again to get a value you will see in TRACE it was again calculated just like last time SUB TEST(X,Y,Z$) was called.

I think I'm understanding now what you talk about, and then you are right about he mechanism. You just used the wrong word.

First, there aren't any variables mentioned in the last quote. X, Y and Z$ are formal parameters.

Now if you CALL TEST(A,B,C$) any changes to the formal parameters will be returned to the actual parameters A,B and C$.

If you instead call it with CALL TEST(12,B,C$) changes to Y and Z$ will be returned to B and C$, but not changes to X, as that would redefine the value of 12.

 

In languages like Pascal, a parameter passed by value creates a copy of the value in the formal parameter. You can change that as much as you like, but nothing happens to the actual parameter, since they are at two different memory locations.

A parameter passed by reference doesn't create a local copy of the value in the formal parameter, but a pointer to the actual parameter. Thus any change to the formal parameter will change the value of the actual one, right there, right then.

 

Now I have not studied how BASIC handles this. It's of course fully possible to indeed create a local copy of the value, not of the reference to the actual parameter, even when it's called by reference, change that local copy as much as needed and upon SUBEND copy all these local values back to the actual parameters. Considering that BASIC allows the formal parameter to be called both by value and by reference in the same program (Pascal doesn't - you have to make up your mind and stay with that), this may be the way to do it. Then you have temporary values, that are created and discarded, and may be subject to BASIC's memory management with garbage collection and so on.

 

But they aren't what we normally call temporary variables. Variables are things we can see and command.

 

Here's a small program to show what I mean. I omitted the line numbers, since they aren't needed anyway.

A=4
CALL ADDER(A)
PRINT A
A=7
CALL ADDER(A)
PRINT A
CALL ADDER(A)
PRINT A
SUB ADDER(X)
P=P+X
X=P
SUBEND

When you run this program you'll get the result

4

11

22

This shows that the local variable P is not temporary in BASIC. It's reset to zero when execution starts and it remembers its value across calls. So it's a static local variable.

Now if you run this seemingly equivalent Pascal program

program test;

var a: integer;

  procedure adder(var x:integer);
  var p: integer;

  begin
    p := p+x;
    x := p;
  end;

begin
  a := 4;
  adder(a);
  writeln(a);
  a := 7;
  adder(a);
  writeln(a);
  adder(a);
  writeln(a);
end.

you would not get the same result. Instead you'll get three random integers.

This is because first, Pascal doesn't set the local variable p to anything at all when execution of adder starts. It will be what happens to be in memory where p is created. Second, upon exiting the adder procedure, the activation record on the stack for adder is discarded, and the local variables in adder goes with that. So this is an example of a temporary local variable.

 

So the reason for this debate is that you called these temporary values (the formal parameters in one case, the intermediate calculation results in the other) temporary variables. They for sure are temporary, but not variables.

[+Vorticon]

9 hours ago, senior_falcon said:

Subs are super versatile for all the reasons Vorticon mentions. There is a speed penalty which might sometimes argue for a normal GOSUB when running in XB and performance is important.

I don't think the speed penalty is too serious with compiled code

So I did a quick XB test to see if I could detect a time difference between calling a standard GOSUB versus a SUB and there was no appreciable difference that I could detect.

 

 

100 CALL CLEAR :: CALL INIT
110 PRINT "STANDARD SUB TEST"
120 CALL LOAD(-31879,0)
130 GOSUB 220
140 CALL PEEK(-31879,ST)
150 PRINT "NAMED SUB TEST"
160 CALL LOAD(-31879,0)
170 CALL TEST(100)
180 CALL PEEK(-31879,C)
190 PRINT "GOSUB:";ST/60;"SEC"
200 PRINT "CALL SUB:";C/60;"SEC"
210 END
220 REM  STANDARD SUB
230 FOR I=1 TO 100
240 NEXT I
250 RETURN
260 REM  CALLED SUB
270 SUB TEST(N)
280 FOR I=1 TO N
290 NEXT I
300 SUBEND

 

[Retrospect]

@Vorticon that .01 of a second could mean life or death against a weaponized saucer 🤪

[senior_falcon]

8 hours ago, RXB said:

If you call the Variables in that routine you have to use the same SUB TEST(X,Y,Z$) or you can only get those values when inside that SUB.

If you call it again to get a value you will see in TRACE it was again calculated just like last time SUB TEST(X,Y,Z$) was called.

This is not that hard to figure out just using XB TRACE COMMAND!

I seem to be missing something. This reads like something an early generation chatbot would write. It is all English, but somehow never quite adds up.

Apersson seems to have made some sense of it, but he is smarter than I am. This is just my opinion.

 

We have a little less than two weeks to iron this out before the hammer drops, so...

 

You make these statements:

Lastly any SUB programs use TEMPORARY variables thus will trigger a garbage collection more often than normal variables as they are not TEMPORARY.

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$)

 

Please post one or more XB programs that show this effect. Then please walk me through it.

Explain what TRACE is showing me.

Tell me what it is that will cause garbage collection to be performed more frequently than it would be if a simple GOSUB were used.

 

 I require proof of YOUR OPINION.

 

 

 

 

 

 

Edited March 11, 2023 by senior_falcon

[senior_falcon]

36 minutes ago, Vorticon said:

So I did a quick XB test to see if I could detect a time difference between calling a standard GOSUB versus a SUB and there was no appreciable difference that I could detect.

Interesting. I ran these two programs:

10 FOR I=1 TO 4000
20 CALL TEST(I)
30 NEXT I
40 END
100 SUB TEST(X)
101 SUBEND

      and

10 FOR I=1 TO 4000
20 GOSUB 100
30 NEXT I
40 END
100 RETURN

These do nothing other than CALL TEST and SUBEND or GOSUB and RETURN

The first took about 45 seconds and the second took 24 seconds, and an empty loop took 15 seconds. So in this example it takes 30 seconds to do 4000 CALL TEST(X) for .0075 seconds per CALL.

It takes 9 seconds to 4000 GOSUBS for .0023 seconds per GOSUB

When passing 6 variables it takes 73 seconds (when you subtract the FOR/NEXT overhead) so that is  .0183 seconds per CALL TEST. (Remember that you don't have to pass values when you GOSUB.)

So when passing 6 values CALL test is .0183 seconds and GOSUB is .0023 seconds.

 

So, yes, CALL takes longer. But is it an "appreciable difference?" I would say that generally it would not be. The subroutines will actually do something before returning and of course those instructions would take the same amount of time either way you do it. So the extra .016 seconds will usually be insignificant.

 

There is one more thing. These programs are very short. To GOSUB, XB has to wade through the line number table to find the line to GOTO. That takes time. Less if it is to one of the higher number lines, and more if it is to a lower number line. It may well be that in a long program, CALL might actually be faster.

 

So I am not certain whether I stand corrected, but I can say that I stand enlightened.
 

[GDMike]

14 hours ago, RXB said:

Kenau Reves is my favorite that can sword fight and gun fight better than most in Hollywood.

Also, he lives in a average American middle-class home and is not a racist or homophobe or sexist.

Watch | Facebook

 

 

Our world went to sht when we started believing a "faKEbook" post. Stick to the subject..my popcorn has run out.

[+InsaneMultitasker]

1 hour ago, GDMike said:

Our world went to sht when we started believing a "faKEbook" post. Stick to the subject..my popcorn has run out.

Hah!  I have spare popcorn here!

 

I woke up asking myself why many of the XB programming topics turn into arguments about what the interpreter/ROM/GPL do behind the scenes. As my old manager used to say, "I don't want to know how the hot dog is made, I just want to eat it". 

[GDMike]

4 minutes ago, InsaneMultitasker said:

Hah!  I have spare popcorn here!

 

I woke up asking myself why many of the XB programming topics turn into arguments about what the interpreter/ROM/GPL do behind the scenes. As my old manager used to say, "I don't want to know how the hot dog is made, I just want to eat it". 

How did our real world go from 1980 GROM to 1950 pilGROM,

uh.. pilgrim .

[Retrospect]

2 hours ago, GDMike said:

Our world went to sht when we started believing a "faKEbook" post

This is too true.   

[+Ksarul]

25 minutes ago, Retrospect said:

This is too true.  There are articles for example, that state John Wayne did not say what he said .. there are people that defended wayne.  But the folks who are race-obsessed will read one thing saying he did it, and run with it , without bothering to read the counter-articles.  And I  tell you why they do that - because it suits their obsession.  It wouldn't do , would it, to find a counter article and have a 50/50 situation.  Oh hell no.  These obsessed people are not truly happy.  They're just not.  And they make those around them unhappy.  Because they can't shut the hell up about that one thing all of the time.  

Hmmmm, you seem to have perfectly encapsulated my wife's response to pretty much any situation of discussion. You missed one minor point in the sequence though: these people get their only source of temporary joy by making those around them unhappy--because if those other people are actually happy, that places the behavior of the obsessed person in a bad light, which is something that must not be. . .as we all know that the obsessed are perfect in every way.

 

Thanks for the lowdown @Retrospect, you made my day!

[Retrospect]

7 minutes ago, Ksarul said:

Thanks for the lowdown @Retrospect, you made my day!

You're welcome Ksarul, although I did edit the comment afterwards, you must have caught it just in time.  I edited it 'cos I thought I was just droning on!  ha.

[RXB]

9 hours ago, apersson850 said:

Because I know computers.

I think I'm understanding now what you talk about, and then you are right about he mechanism. You just used the wrong word.

First, there aren't any variables mentioned in the last quote. X, Y and Z$ are formal parameters.

Now if you CALL TEST(A,B,C$) any changes to the formal parameters will be returned to the actual parameters A,B and C$.

If you instead call it with CALL TEST(12,B,C$) changes to Y and Z$ will be returned to B and C$, but not changes to X, as that would redefine the value of 12.

 

In languages like Pascal, a parameter passed by value creates a copy of the value in the formal parameter. You can change that as much as you like, but nothing happens to the actual parameter, since they are at two different memory locations.

A parameter passed by reference doesn't create a local copy of the value in the formal parameter, but a pointer to the actual parameter. Thus any change to the formal parameter will change the value of the actual one, right there, right then.

 

Now I have not studied how BASIC handles this. It's of course fully possible to indeed create a local copy of the value, not of the reference to the actual parameter, even when it's called by reference, change that local copy as much as needed and upon SUBEND copy all these local values back to the actual parameters. Considering that BASIC allows the formal parameter to be called both by value and by reference in the same program (Pascal doesn't - you have to make up your mind and stay with that), this may be the way to do it. Then you have temporary values, that are created and discarded, and may be subject to BASIC's memory management with garbage collection and so on.

 

But they aren't what we normally call temporary variables. Variables are things we can see and command.

 

Here's a small program to show what I mean. I omitted the line numbers, since they aren't needed anyway.

A=4
CALL ADDER(A)
PRINT A
A=7
CALL ADDER(A)
PRINT A
CALL ADDER(A)
PRINT A
SUB ADDER(X)
P=P+X
X=P
SUBEND

When you run this program you'll get the result

4

11

22

This shows that the local variable P is not temporary in BASIC. It's reset to zero when execution starts and it remembers its value across calls. So it's a static local variable.

Now if you run this seemingly equivalent Pascal program

program test;

var a: integer;

  procedure adder(var x:integer);
  var p: integer;

  begin
    p := p+x;
    x := p;
  end;

begin
  a := 4;
  adder(a);
  writeln(a);
  a := 7;
  adder(a);
  writeln(a);
  adder(a);
  writeln(a);
end.

you would not get the same result. Instead you'll get three random integers.

This is because first, Pascal doesn't set the local variable p to anything at all when execution of adder starts. It will be what happens to be in memory where p is created. Second, upon exiting the adder procedure, the activation record on the stack for adder is discarded, and the local variables in adder goes with that. So this is an example of a temporary local variable.

 

So the reason for this debate is that you called these temporary values (the formal parameters in one case, the intermediate calculation results in the other) temporary variables. They for sure are temporary, but not variables.

Sorry this sounds like the logic Flat Earth people use or Conspiracy Theory people use.

[RXB]

3 hours ago, senior_falcon said:

Interesting. I ran these two programs:

10 FOR I=1 TO 4000
20 CALL TEST(I)
30 NEXT I
40 END
100 SUB TEST(X)
101 SUBEND

      and

10 FOR I=1 TO 4000
20 GOSUB 100
30 NEXT I
40 END
100 RETURN

These do nothing other than CALL TEST and SUBEND or GOSUB and RETURN

The first took about 45 seconds and the second took 24 seconds, and an empty loop took 15 seconds. So in this example it takes 30 seconds to do 4000 CALL TEST(X) for .0075 seconds per CALL.

It takes 9 seconds to 4000 GOSUBS for .0023 seconds per GOSUB

When passing 6 variables it takes 73 seconds (when you subtract the FOR/NEXT overhead) so that is  .0183 seconds per CALL TEST. (Remember that you don't have to pass values when you GOSUB.)

So when passing 6 values CALL test is .0183 seconds and GOSUB is .0023 seconds.

 

So, yes, CALL takes longer. But is it an "appreciable difference?" I would say that generally it would not be. The subroutines will actually do something before returning and of course those instructions would take the same amount of time either way you do it. So the extra .016 seconds will usually be insignificant.

 

There is one more thing. These programs are very short. To GOSUB, XB has to wade through the line number table to find the line to GOTO. That takes time. Less if it is to one of the higher number lines, and more if it is to a lower number line. It may well be that in a long program, CALL might actually be faster.

 

So I am not certain whether I stand corrected, but I can say that I stand enlightened.
 

Well thank you for that.

[RXB]

1 hour ago, InsaneMultitasker said:

Hah!  I have spare popcorn here!

 

I woke up asking myself why many of the XB programming topics turn into arguments about what the interpreter/ROM/GPL do behind the scenes. As my old manager used to say, "I don't want to know how the hot dog is made, I just want to eat it". 

Exactly, I find it fascinating when people tell you something so precise about XB,  but have never read the Source Code of GPL or ROM of XB.

It hits me the same way you hear Flat Earth people talk about science.

You show them the source code and they cannot read it so just assume they know exactly the answer with no proof?

[Retrospect]

@RXB .... If you like, I can change the thread title to "Temporary Variables, John Wayne, Keanu f**king Reeves and Flat Earth People"    

 

 

[jrhodes]

16 minutes ago, RXB said:

Sorry this sounds like the logic Flat Earth people use or Conspiracy Theory people use.

@apersson850 has shown you example programs that can be run by anyone with predictable, repeatable, results.

That's not "theory", it's fact backed by evidence and documented examples. Sorry if you have a problem accepting that.

Edited March 11, 2023 by jrhodes

[RXB]

Just now, Retrospect said:

@RXB .... If you like, I can change the thread title to "Temporary Variables, John Wayne, Keanu f**king Reeves and Flat Earth People"    

 

 

Hmm I did not start this did I?

It all started when I made a statement about how XB works internally and got attacked for saying that.

I asked for the Source Code of what they said how it works and got crickets or attacked more.

Then it got personal and again I did not do that to anyone, but just posted the source code, so I am not the problem here.

As for personal heros I prefer people that have not given personal interviews and shown own words are racist, sexist and homophobic.

Yes it was the 1970's, but all kinds of people were not like that and were also hero's.

Betty White for example is another personal hero.

 

If you are also attacking me fine go for it. Does not change what I said about XB  internal structure of variables or calls or gosub or goto.

[RXB]

7 minutes ago, jrhodes said:

@apersson850 has shown you example programs that can be run by anyone with predictable, repeatable, results.

That's not "theory", it's fact backed by evidence and documented examples. Sorry if you have a problem accepting that.

Show the XB GPL and ROM source code as that is the subject here not Pascal!

[Retrospect]

1 minute ago, RXB said:

If you are also attacking me fine go for it.

That was not an actual attack.  

 

I think I see the problem now though.

[Retrospect]

@RXB .... @apersson850  was just showing you some examples, I can't claim to understand what was written.  He showed examples and stated that you might have gotten the word "temporary variable" or "value" or whatever, by mistake.  And you then said his logic was akin to Flat Earth people.

 

I jokingly said shall I change the thread title to include such flat earth people and you assume an attack.  

 

WHY are you like you are?  I'm not trying to be unkind here Rich, I really aren't.  I'm not trying to attack either.  If I was you'd know about it.  

[jrhodes]

2 minutes ago, Retrospect said:

WHY are you like you are?

Toxic people don't realize they are toxic.

[RXB]

Anyway, back to the original topic.

In XB a CALL of any kind requires the ROM to search for the name in the SYMbol table and find that name like HCHAR and if it cannot find that name 

it searches for Variables and during that search it looks to see if it is a DEF or a SUB program new name.

This is the internal structure of how XB works from GPL and ROM.

There is a NUD table that has a listing of all the routine names in XB including all symbols like , or DISTANCE or PRINT or :: is also a token.

Variables are created and set up in VDP memory and either in Console only or 32K depending on if there is a 32K or not.

Variables are either Numeric 8 byte Floating Point or Strings.

 

[+OLD CS1]

 

 

[jrhodes]

24 minutes ago, RXB said:

Show the XB GPL and ROM source code as that is the subject here not Pascal!

The subject here in this thread is temporary variables and what they are or are not in regards to XB sub routines.

The first example by @apersson850 is XB compatible.

Don't like pascal examples? Ignore them. He made a fine enough point with his post even without looking at the pascal code.

Your attitude has earned you a permanent spot on my ignore list.

Edited March 11, 2023 by jrhodes

[RXB]

1 minute ago, jrhodes said:

The subject here in this thread is temporary variables and what they are or are not in regards to XB sub routines.

The first example by @apersson850 is XB compatible.

Don't like pascal examples? Ignore them. He made a fine enough point with his post even without looking at the pascal code.

Your attitude has earned you a permanent spot on my ignore list.

My attitude? Scroll back and look at yours!