Forum - MCS Electronics

 

FAQFAQ SearchSearch RegisterRegister Log inLog in

Local Variables

 
This forum is locked: you cannot post, reply to, or edit topics.   This topic is locked: you cannot edit posts or make replies.    www.mcselec.com Forum Index -> BASCOM-AVR Archive
View previous topic :: View next topic  
Author Message
njepsen

Bascom Member



Joined: 13 Aug 2007
Posts: 414

newzealand.gif
PostPosted: Mon Oct 13, 2014 8:59 pm    Post subject: Local Variables Reply with quote

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
View user's profile
MWS

Bascom Member



Joined: 22 Aug 2009
Posts: 1915

blank.gif
PostPosted: Mon Oct 13, 2014 10:07 pm    Post subject: Re: Local Variables Reply with quote

njepsen wrote:
Unfortunately the compliler doesnt recognise 'end sub' as executable code.
Question Question Question

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
View user's profile
njepsen

Bascom Member



Joined: 13 Aug 2007
Posts: 414

newzealand.gif
PostPosted: Mon Oct 13, 2014 10:12 pm    Post subject: Reply with quote

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
View user's profile
MWS

Bascom Member



Joined: 22 Aug 2009
Posts: 1915

blank.gif
PostPosted: Mon Oct 13, 2014 11:45 pm    Post subject: Reply with quote

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
View user's profile
njepsen

Bascom Member



Joined: 13 Aug 2007
Posts: 414

newzealand.gif
PostPosted: Tue Oct 14, 2014 1:24 am    Post subject: Reply with quote

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
View user's profile
Paulvk

Bascom Member



Joined: 28 Jul 2006
Posts: 1207
Location: SYDNEY

australia.gif
PostPosted: Tue Oct 14, 2014 2:54 am    Post subject: Reply with quote

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
View user's profile
njepsen

Bascom Member



Joined: 13 Aug 2007
Posts: 414

newzealand.gif
PostPosted: Wed Oct 22, 2014 1:27 am    Post subject: Reply with quote

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
View user's profile
Paulvk

Bascom Member



Joined: 28 Jul 2006
Posts: 1207
Location: SYDNEY

australia.gif
PostPosted: Wed Oct 22, 2014 3:46 am    Post subject: Reply with quote

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
View user's profile
njepsen

Bascom Member



Joined: 13 Aug 2007
Posts: 414

newzealand.gif
PostPosted: Wed Oct 22, 2014 3:52 am    Post subject: Reply with quote

Good point Paul; obviously in any sub they would be re-assigned to a new value anyway.
_________________
Neil
Back to top
View user's profile
MWS

Bascom Member



Joined: 22 Aug 2009
Posts: 1915

blank.gif
PostPosted: Wed Oct 22, 2014 3:09 pm    Post subject: Reply with quote

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. Very Happy
Back to top
View user's profile
Display posts from previous:   
This forum is locked: you cannot post, reply to, or edit topics.   This topic is locked: you cannot edit posts or make replies.    www.mcselec.com Forum Index -> BASCOM-AVR Archive All times are GMT + 1 Hour
Page 1 of 1

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You cannot attach files in this forum
You cannot download files in this forum