Has anything been written anywhere about the scope and life-cycle of GCB variables? Do variable-to-ram assignments ever get destroyed or recycled? Is there a way to free up ram by destroying variable-to-ram assignments? Do variables have differences in scope depending on where they're assigned/used in the program?
Joe
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I have not read or found anything with respect this subject.
From my knowledge.
Scope - every variable is global.
Life cycle - once a variable is defined as used it persists.
Aliasing - You can use aliasing to reduce memory usage but as a all variables are global you must be careful.
Anyone else got anything to add?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
That's pretty much it! The only thing to add, variables are global, but if they are defined inside a particular subroutine then their type isn't. Some example code:
Dim MainVar As Byte
Dim OtherVar As Word
MainVar = 128
OtherVar = 514
DemoSub
'At this point:
'MainVar is a byte, value 128
'OtherVar is a word, value 514
'Counter is a byte, value 2
'(Byte is default type, but location shared with that of Counter in DemoSub. High byte ignored)
Sub DemoSub
Dim Counter As Word
Counter = 2050
'At this point:
'MainVar and OtherVar as byte and word, as in main routine
'Counter is a word, value 2050
End Sub
Things have been done this way to minimise the size of the generated assembly code. At some point, variables local to particular subroutines may be implemented. If this happens, there will be some #config option to enable/disable this. As a general guide though, it's best to define any shared variables near the start of the program for easier readability.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Just to clarify, when you say byte is default type, that means the
Dim MainVar As Byte is unnecessary.
MainVar = 128 takes care of the Dim portion automatically, correct?
But I don't understand the counter is 2 as it was never used prior and once the subroutine DemoSub defines Counter as a word, isn't it a word variable throughout?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Yes, technically there's no need to Dim anything as a byte, that happens automatically. Counter is 2 because the variable is global but the type isn't. In DemoSub, it's a word. But anywhere else, it's a byte unless otherwise specified. If read in the main routine, it will be treated as a byte, and only the low 8 bits will be returned. The low 8 bits of 2050 are 2.
(The global variable, local type idea is admittedly a bit silly now. It made sense in 2006 when GCBASIC only supported 16F chips and its 16 bit arithmetic support was shaky at best, but maybe there is a better way now?)
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I still have some questions. If a variable is DIM'd in a Sub, is RAM reserved for it according to the size it was DIM'd to, eg, 2 bytes of RAM for a Word? If that variable is then used outside the Sub, it's treated as a Byte, but are there still 2 bytes reserved for it? This was what triggered my more general question about the life-cycle of variables and associated RAM assignments.
What I'm discovering is that, to avoid unexpected behavior, I should try to DIM all my variables at the beginning of the program. Are there any reasons why/when variables should be DIM'd inside the Sub they're used in?
Joe
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The main reason for keeping the type inside the subroutine was for this scenario
- A subroutine uses a temporary variable, say of type byte, and relies on it overflowing
- Another subroutine uses a temporary variable of the same name, but of word type
- If the first subroutine is already in the program, and then the second one is added, the behaviour of the first one won't change at all due to the addition of the second one.
But because the compiler doesn't currently have any concept of local variables, it needs to put all variables with the same name into the same RAM location.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I'm finding that if I DIM a variable inside a sub, that variable isn't visible to code outside the sub. Is that correct? Does this mean I can reuse the same variable name in different subs so long as the variable name is declared in each sub it's used in?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
If there are two variables with the same name, they will be placed in the same memory location. So you can reuse the same name in two subs, and you can make the variables different types, but writing to the variable in one sub will overwrite the value from the other sub.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Has anything been written anywhere about the scope and life-cycle of GCB variables? Do variable-to-ram assignments ever get destroyed or recycled? Is there a way to free up ram by destroying variable-to-ram assignments? Do variables have differences in scope depending on where they're assigned/used in the program?
Joe
I have not read or found anything with respect this subject.
From my knowledge.
Scope - every variable is global.
Life cycle - once a variable is defined as used it persists.
Aliasing - You can use aliasing to reduce memory usage but as a all variables are global you must be careful.
Anyone else got anything to add?
That's pretty much it! The only thing to add, variables are global, but if they are defined inside a particular subroutine then their type isn't. Some example code:
Dim MainVar As Byte Dim OtherVar As Word MainVar = 128 OtherVar = 514 DemoSub 'At this point: 'MainVar is a byte, value 128 'OtherVar is a word, value 514 'Counter is a byte, value 2 '(Byte is default type, but location shared with that of Counter in DemoSub. High byte ignored) Sub DemoSub Dim Counter As Word Counter = 2050 'At this point: 'MainVar and OtherVar as byte and word, as in main routine 'Counter is a word, value 2050 End SubThings have been done this way to minimise the size of the generated assembly code. At some point, variables local to particular subroutines may be implemented. If this happens, there will be some #config option to enable/disable this. As a general guide though, it's best to define any shared variables near the start of the program for easier readability.
Just to clarify, when you say byte is default type, that means the
Dim MainVar As Byte is unnecessary.
MainVar = 128 takes care of the Dim portion automatically, correct?
But I don't understand the counter is 2 as it was never used prior and once the subroutine DemoSub defines Counter as a word, isn't it a word variable throughout?
Yes, technically there's no need to Dim anything as a byte, that happens automatically. Counter is 2 because the variable is global but the type isn't. In DemoSub, it's a word. But anywhere else, it's a byte unless otherwise specified. If read in the main routine, it will be treated as a byte, and only the low 8 bits will be returned. The low 8 bits of 2050 are 2.
(The global variable, local type idea is admittedly a bit silly now. It made sense in 2006 when GCBASIC only supported 16F chips and its 16 bit arithmetic support was shaky at best, but maybe there is a better way now?)
Thanks for the reply Hugh.
I still have some questions. If a variable is DIM'd in a Sub, is RAM reserved for it according to the size it was DIM'd to, eg, 2 bytes of RAM for a Word? If that variable is then used outside the Sub, it's treated as a Byte, but are there still 2 bytes reserved for it? This was what triggered my more general question about the life-cycle of variables and associated RAM assignments.
What I'm discovering is that, to avoid unexpected behavior, I should try to DIM all my variables at the beginning of the program. Are there any reasons why/when variables should be DIM'd inside the Sub they're used in?
Joe
The main reason for keeping the type inside the subroutine was for this scenario
- A subroutine uses a temporary variable, say of type byte, and relies on it overflowing
- Another subroutine uses a temporary variable of the same name, but of word type
- If the first subroutine is already in the program, and then the second one is added, the behaviour of the first one won't change at all due to the addition of the second one.
But because the compiler doesn't currently have any concept of local variables, it needs to put all variables with the same name into the same RAM location.
Just to clarify though...
I'm finding that if I DIM a variable inside a sub, that variable isn't visible to code outside the sub. Is that correct? Does this mean I can reuse the same variable name in different subs so long as the variable name is declared in each sub it's used in?
@hugh. Can you answer?
If there are two variables with the same name, they will be placed in the same memory location. So you can reuse the same name in two subs, and you can make the variables different types, but writing to the variable in one sub will overwrite the value from the other sub.