| View previous topic :: View next topic |
| Author |
Message |
njepsen
Joined: 13 Aug 2007
Posts: 469
|
 Posted: Mon Oct 13, 2014 8:59 pm Post subject: Local Variables |
 |
|
I wanted to comment out a sub, and inserted exit sub as shown below , rather than find, and comment out all of the calls throughout the main code.
The result was that the code crashed about once an hour, and it took me some time to realise why.
The exit sub must go after the two locals because they must go after any executable code.
Unfortunately the compliler doesnt recognise 'end sub' as executable code.
| Code: |
sub check_for_ringing()
exit sub 'new line added
local ringvolts as byte
local ringmsg as string*20
code
blah
blah
blah
end sub
|
(BASCOM-AVR version : 2.0.7.7 )
_________________
Neil |
|
| Back to top |
|
 |
MWS
Joined: 22 Aug 2009
Posts: 2262
|
| Posted: Mon Oct 13, 2014 10:07 pm Post subject: Re: Local Variables |
|
|
| njepsen wrote: | | Unfortunately the compliler doesnt recognise 'end sub' as executable code. |
I see it as a compiler problem.
As described by the help, the exit sub jumps to a label at the end of the sub, where the Y-pointer is cleaned up.
The problem is: locals are created at the exact line in code.
The procedure is as follows:
For each local a two-byte pointer is created, this pointer is stored indexed by the Y-pointer, while the Y-pointer is decreased by two.
As the sub exits, it assumes an altered Y-pointer and tries to clean up, which is done by increasing the Y-pointer by the same numbers decreased before.
But if preceded by an exit sub, the locals are not created and thus the Y-pointer is not altered at first - but increased after.
At return of the sub, the Y-pointer is messed up and the thing goes nuclear.
Can be fixed, if locals are created in any case, doesn't matter, where they are placed within a sub or function. |
|
| Back to top |
|
|
njepsen
Joined: 13 Aug 2007
Posts: 469
|
| Posted: Mon Oct 13, 2014 10:12 pm Post subject: |
|
|
I only tumbled to the problem after finally determining that the processor crashed just after the sub that I had killed, had been called. I seemed to remember from somewhere a note that locals must be written "before" executable code. The hour between crashes didnt help.
_________________
Neil |
|
| Back to top |
|
|
MWS
Joined: 22 Aug 2009
Posts: 2262
|
| Posted: Mon Oct 13, 2014 11:45 pm Post subject: |
|
|
| njepsen wrote: | | I seemed to remember from somewhere a note that locals must be written "before" executable code. |
If this is the case and if the compiler's behavior should not be altered, then a warning in the help either at "local" or "exit sub" is recommendable.
| Quote: | | The hour between crashes didnt help. |
If the "clockwork" of the Y-pointer runs out of step, weird things may happen.
The time between crashes depends on how often this sub is called, as every time it's called, the Y-pointer comes closer to the other stacks, soft and hard.
If they meet, data corruption or a crash will happen. |
|
| Back to top |
|
|
njepsen
Joined: 13 Aug 2007
Posts: 469
|
| Posted: Tue Oct 14, 2014 1:24 am Post subject: |
|
|
You are absolutely correct Ludwig. The sub was only called every 5 seconds so it took about an hour to fail; i wrote a test loop that called it every 100ms, and it failed in very quick time, and at exactly the same number of interations, which was the clue I needed.
If you write code like this:
| Code: |
sub anyname()
if something then
local variable name as byte
blah
blah
end if
end sub
|
the compiler will tell you the local is in the wrong place and must be "before any executable code" , but it seems it doesnt know about exit sub.
cheers
_________________
Neil |
|
| Back to top |
|
|
Paulvk
Joined: 28 Jul 2006
Posts: 1257
Location: SYDNEY
|
| Posted: Tue Oct 14, 2014 2:54 am Post subject: |
|
|
Have to try and keep this in mind!
Maybe something that may change in the totally new version that mark is writing
Look forward to it being released and even happy to pay for it.
All that work should get paid for!!
Regards Paul |
|
| Back to top |
|
|
njepsen
Joined: 13 Aug 2007
Posts: 469
|
| Posted: Wed Oct 22, 2014 1:27 am Post subject: |
|
|
I assume this is Ok ( because it compliles OK) | Code: |
sub Read_vaisala()
#if isvaisala = 1
local tempstr1 as string * 100
local tempstr2 as string * 20
local temps as single
Retries = 0
Do
Incr Retries
print #1 , ""
Print #1 , ">> reading Vaisala weather"
etc
etc
loop
#endif
end sub
|
but in the interests of not getting into bad habits, this is better?
I realise that the local variables will be created & trashed every time the sub is called.
| Code: |
sub Read_vaisala()
local tempstr1 as string * 100
local tempstr2 as string * 20
local temps as single
#if isvaisala = 1
Retries = 0
Do
Incr Retries
print #1 , ""
Print #1 , ">> reading Vaisala weather"
etc
etc
loop
#endif
end sub
|
_________________
Neil |
|
| Back to top |
|
|
Paulvk
Joined: 28 Jul 2006
Posts: 1257
Location: SYDNEY
|
| Posted: Wed Oct 22, 2014 3:46 am Post subject: |
|
|
Hello Neil
"I realise that the local variables will be created & trashed every time the sub is called."
Not trashed, I found out that they may still contain their data next time the sub is called so a good Idea to clear them and not to expect them to be empty.
Regards Paul |
|
| Back to top |
|
|
njepsen
Joined: 13 Aug 2007
Posts: 469
|
| Posted: Wed Oct 22, 2014 3:52 am Post subject: |
|
|
Good point Paul; obviously in any sub they would be re-assigned to a new value anyway.
_________________
Neil |
|
| Back to top |
|
|
MWS
Joined: 22 Aug 2009
Posts: 2262
|
| Posted: Wed Oct 22, 2014 3:09 pm Post subject: |
|
|
| Paulvk wrote: | | I found out that they may still contain their data next time the sub is called so a good Idea to clear them and not to expect them to be empty. |
In case the Frame is not overwritten by other locals and the Y-pointer is the same, a local contain its last value.
Btw., the help is pretty clear about locals, filed under Local:
| Quote: | | Notice that a LOCAL variable is not initialized. It will contain a value that will depend on the value of the FRAME data. So you can not assume the variable is 0. If you like it to be 0, you need to assign it. |
So, not much room to discover something unexpected.  |
|
| Back to top |
|
|
|
FAQ
Search
Register
Log in
