Initialization of local variables in procedures

[clovepower]

OK, I am posting this here, because it has to do with stack (I think). Apologies if this is not the right thread.

I am running the below code in the Dragon target (I get an IDE error if I use VIC 20) .

Code: Select all

PROCEDURE inc
	DIM c AS BYTE
	++c
	RETURN c
END PROC

10 PRINT inc[]
20 GOTO 10

This prints an increasing number:

Code: Select all

1
2
3
...

Is this what is expected? Shouldn't c be set to 0 each time the procedure is entered (as the rule is a variable is always 0 when created)?. I guess c is "created" once at program start, but intuitively if I find a DIM I feel the variable should be initialized at that point.

Still, whatever the language does it is fine to me, just checking whether this is a feature or a bug

[spotlessmind1975]

Hi clovepower!

I am running the below code in the Dragon target (I get an IDE error if I use VIC 20) .

I received the error report, and I will work in order to make it working again under VIC-20 with a HOTFIX.

If you have not already done so, I recommend that you activate the automatic detection of new versions of the IDE (FILE > Preferences > Software updates > ENABLE HOTFIX/COLDFIX CHECK) so that, as soon as the fix is ​​published, you will be suggested to update the compiler or compilers (depending on the selected targets, of course! ) .

Is this what is expected? Shouldn't c be set to 0 each time the procedure is entered (as the rule is a variable is always 0 when created)?. I guess c is "created" once at program start, but intuitively if I find a DIM I feel the variable should be initialized at that point.

Yes, the behavior is correct.

Now, it is true that the DIM implies the definition of the variable: however, this behavior is what is expected with a "global" variable, i.e. one defined at the main program level. Being defined within the procedure, the semantics change slightly.

Since the language is stackless, the storage space is not allocated at the time it is called (hence the initialization at each call) but at the start of the program. It follows that this variable will be initialized to zero (or to whatever constant is), obviously, but only at the first call of the procedure (or, in some more stringent targets like consoles, at the start of the program).

In practice you could think of local variables within procedures as "static" variables in a classical programming language. So their value is maintained between calls. If you would like to have the behavior of a classic local variable, the actual workaround is to assign a value before starting, like this:

Code: Select all

PROCEDURE inc
	DIM c AS BYTE
	c = 0
	...
END PROC

The advantage of this approach lies in the fact that local variables have the same computational cost as global ones, and on 8-bit computers it is essential. Moreover, it is possible, with a simple transposition, to transform a sequential algorithm into a parallel one, precisely because the value of the variables is well known ad each moment. Ok, this is probably not my best possible example, but it's just to give you the idea:

Code: Select all

PARALLEL PROCEDURE inc
	DIM c(...) AS BYTE : REM maximum number of simultaneous threads
	[c] = 0
	...
END PROC

OK, I am posting this here, because it has to do with stack (I think). Apologies if this is not the right thread.

Don't worry! One of the advantages of using a forum software is that it has excellent tools for rearranging message exchanges afterwards. To make the topic clearer, I thought I'd split the message into a new thread with a more relevant title, so that in the future anyone will be able to find it more easily. Feel free to tell me if the title doesn't seem appropriate to you, I'll change it.

[clovepower]

OK, understood, thanks for the explanation. I see ugBASIC is indeed doing a lot of optimization I was not thinking of