Hi
clovepower!
clovepower wrote: ↑Wed Jul 03, 2024 10:59 pm
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!
) .
clovepower wrote: ↑Wed Jul 03, 2024 10:59 pm
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
clovepower wrote: ↑Wed Jul 03, 2024 10:59 pm
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.
