"Steve at fivetrees" <steve@NOSPAMTAfivetrees.com> wrote in message 
news:X-KdnSxhfs6mIuLYRVnyugA@pipex.net...
> "galapogos" <goister@gmail.com> wrote in message 
> news:1165975298.329026.144630@n67g2000cwd.googlegroups.com...
>> Hi,
>> Is it possible to goto a label that's not in the same functions? I've
>> always been taught that gotos are evil so I don't have much experience
>> with it, but I'm currently in a situation where I think I might have to
>> use it.
>
> No, you don't. Really, you don't.
>
> Instead you need to reconsider your program structure to make such 
> evilness unnecessary.

More specifically, this sounds like a job for a state machine. Put your 
disconnected test at the top of the loop, before the state handlers, and 
force the "oops - disconnected" state, starting with any cleanup necessary.

To put it another way, one can "goto" an exceptional state without having to 
use gotos in code. Much cleaner, more logical, and *way* more maintainable.

Steve
http://www.fivetrees.com 

galapogos wrote:
> CBFalconer wrote:
>> galapogos wrote:
>>> visweswara wrote:
>>>
>>>> You can unconditionally branch to any label using inline asm code.
>>>> (Few compiler support it). As like gotos it is very poor practice
>>>> to call a function from ISR. It is a always advisable to keep ISR
>>>> very short. You can use flag polling.
>>>
>>> Sorry, but what are the pittfalls of calling functions from ISR?
>>
>> None, provided the functions don't call the OS and other
>> non-shareable devices.  Also beware running out of stack space, and
>> using excessive time.  Also any functions called should be fully
>> re-entrant, and return so that the ISR service routine can clean
>> up.
> 
> I don't have an OS for my MCU. I can imagine running out of stack
> space and using excessive time, but I didn't think of making the
> called functions re-entrant. A couple of them aren't. I'll modify
> them so that they are.

The re-entrancy means you don't have to worry about calling them
from a higher priority interrupt that has interrupted the
interrupt.  But that is the precise scenario that can eat stack
space.  Interrupt systems that switch stack on interrupt entry can
also be fatal.  It is much simpler to just use a master stack at
all times, but that means you don't know a-priori the stack
requirements of a system.

Systems that switch stack on OS calls can cause troubles here.  I
always tried to design with a master stack that had access to all
available memory, and checked for available stack space on every
function call or heap call (the heap was always increasing upward,
and the stack decreasing downward).  This works when you have prior
knowledge of the memory map.

-- 
Chuck F (cbfalconer at maineline dot net)
   Available for consulting/temporary embedded and systems.
   <http://cbfalconer.home.att.net>

Anton Erasmus wrote:
> On Thu, 14 Dec 2006 18:56:46 -0500, CBFalconer <cbfalconer@yahoo.com>
> wrote:
> 
>> galapogos wrote:
>>> visweswara wrote:
>>>
>>>> You can unconditionally branch to any label using inline asm code.
>>>> (Few compiler support it). As like gotos it is very poor practice
>>>> to call a function from ISR. It is a always advisable to keep ISR
>>>> very short. You can use flag polling.
>>> Sorry, but what are the pittfalls of calling functions from ISR?
>> None, provided the functions don't call the OS and other
>> non-shareable devices.  Also beware running out of stack space, and
>> using excessive time.  Also any functions called should be fully
>> re-entrant, and return so that the ISR service routine can clean
>> up.
> 
> On  MCUs which are not C friendly it is very seldom the case that one
> can asume all the properties required for calling functions from an
> ISR.  I have had problems with low level functions not being
> re-entrant on and older version of IAR 8051. (IIRC V4.x)
> The code generated for switch statements were not re-entrant. 
> I even had a problem where I compared 2 signed 16 bit integers. 
> This generated a call to a low level routine which were no re-entrant.
> I had to write code that first checked the sign and then do unsigned
> compares to get the compiler to generated code that did not call
> a low level function.
> If one had XDATA space, one could switch to a different memory model,
> where the compiler generated a soft stack in XDATA space. This removed
> all these re-entrancy problem, but the code were MUCH slower and of
> course one had to have XDATA space.
> 
> Regards
>   Anton Erasmus
> 

You can even hit problems on C-friendly architectures like the msp430. 
The hardware multiplier on many small micros is handled outside the 
core, and its state may not be saved by the interrupt routine.

CBFalconer wrote:
> galapogos wrote:
> > visweswara wrote:
> >
> >> You can unconditionally branch to any label using inline asm code.
> >> (Few compiler support it). As like gotos it is very poor practice
> >> to call a function from ISR. It is a always advisable to keep ISR
> >> very short. You can use flag polling.
> >
> > Sorry, but what are the pittfalls of calling functions from ISR?
>
> None, provided the functions don't call the OS and other
> non-shareable devices.  Also beware running out of stack space, and
> using excessive time.  Also any functions called should be fully
> re-entrant, and return so that the ISR service routine can clean
> up.

I don't have an OS for my MCU. I can imagine running out of stack space
and using excessive time, but I didn't think of making the called
functions re-entrant. A couple of them aren't. I'll modify them so that
they are.

CBFalconer wrote:
> galapogos wrote:
> > visweswara wrote:
> >
> >> You can unconditionally branch to any label using inline asm code.
> >> (Few compiler support it). As like gotos it is very poor practice
> >> to call a function from ISR. It is a always advisable to keep ISR
> >> very short. You can use flag polling.
> >
> > Sorry, but what are the pittfalls of calling functions from ISR?
>
> None, provided the functions don't call the OS and other
> non-shareable devices.  Also beware running out of stack space, and
> using excessive time.  Also any functions called should be fully
> re-entrant, and return so that the ISR service routine can clean
> up.

I don't have an OS for my MCU. I can imagine running out of stack space
and using excessive time, but I didn't think of making the called
functions re-entrant. A couple of them aren't. I'll modify them so that
they are.

On Thu, 14 Dec 2006 18:56:46 -0500, CBFalconer <cbfalconer@yahoo.com>
wrote:

>galapogos wrote:
>> visweswara wrote:
>>
>>> You can unconditionally branch to any label using inline asm code.
>>> (Few compiler support it). As like gotos it is very poor practice
>>> to call a function from ISR. It is a always advisable to keep ISR
>>> very short. You can use flag polling.
>> 
>> Sorry, but what are the pittfalls of calling functions from ISR?
>
>None, provided the functions don't call the OS and other
>non-shareable devices.  Also beware running out of stack space, and
>using excessive time.  Also any functions called should be fully
>re-entrant, and return so that the ISR service routine can clean
>up.

On  MCUs which are not C friendly it is very seldom the case that one
can asume all the properties required for calling functions from an
ISR.  I have had problems with low level functions not being
re-entrant on and older version of IAR 8051. (IIRC V4.x)
The code generated for switch statements were not re-entrant. 
I even had a problem where I compared 2 signed 16 bit integers. 
This generated a call to a low level routine which were no re-entrant.
I had to write code that first checked the sign and then do unsigned
compares to get the compiler to generated code that did not call
a low level function.
If one had XDATA space, one could switch to a different memory model,
where the compiler generated a soft stack in XDATA space. This removed
all these re-entrancy problem, but the code were MUCH slower and of
course one had to have XDATA space.

Regards
  Anton Erasmus

On Thu, 14 Dec 2006 18:56:46 -0500, CBFalconer <cbfalconer@yahoo.com>
wrote:

>galapogos wrote:
>> visweswara wrote:
>>
>>> You can unconditionally branch to any label using inline asm code.
>>> (Few compiler support it). As like gotos it is very poor practice
>>> to call a function from ISR. It is a always advisable to keep ISR
>>> very short. You can use flag polling.
>> 
>> Sorry, but what are the pittfalls of calling functions from ISR?
>
>None, provided the functions don't call the OS and other
>non-shareable devices.  Also beware running out of stack space, and
>using excessive time.  Also any functions called should be fully
>re-entrant, and return so that the ISR service routine can clean
>up.

Actually, I've encounted another case, at least once.

In the Microchip C18 C compiler, version 1.x (I can't speak to the
later versions, as I didn't dig into their details as much), they used
static memory for compiler temporaries.  Their live variable analysis
was okay and dealt with the case where code would call functions that
themselves may be separately compiled and use the same temporary space
-- they pushed those statics before making a call, if live variable
analysis showed them necessary.  However, in the case of interrupt
routines, static compile-time analysis fails completely because it's a
dynamic situation.  So if you call a C function from the interrupt
procedure, it's quite possible that your interrupt function
interrupted another C function that hadn't preserved the live, static,
compiler temporaries and that if you then call a C function it might
use them.  Stomping on them, completely.

There was no way to access the names of these variables, at link time.
They were local and not available.  And their locations varied
depending on compilation units, variables, etc.  So no fixed
locations, either.

That is another place I've seen this crop up.  So I'd add the warning
to be cognizant that there may be internal static variables (compiler
generated or library) that one needs to preserve and which are not
documented or accessible by symbol or address.

Jon

galapogos wrote:
> visweswara wrote:
>
>> You can unconditionally branch to any label using inline asm code.
>> (Few compiler support it). As like gotos it is very poor practice
>> to call a function from ISR. It is a always advisable to keep ISR
>> very short. You can use flag polling.
> 
> Sorry, but what are the pittfalls of calling functions from ISR?

None, provided the functions don't call the OS and other
non-shareable devices.  Also beware running out of stack space, and
using excessive time.  Also any functions called should be fully
re-entrant, and return so that the ISR service routine can clean
up.

-- 
Chuck F (cbfalconer at maineline dot net)
   Available for consulting/temporary embedded and systems.
   <http://cbfalconer.home.att.net>

visweswara wrote:
> You can unconditionally branch to any label using inline asm code. (
> Few compiler support it).As like gotos it is very poor practice to call
> a function from ISR. It is a always advisable to keep ISR very short.
> You can use flag polling.

Sorry, but what are the pittfalls of calling functions from ISR?

Anyway, thanks for all the help so far. A lot of this is over my head,
I'm still pretty new to embedded programming. Anyway, I think I'm fine
with just checking for the flag all over the place :)

Vladimir Vassilevsky wrote:

> Here is another solution: run the processing loop as the very bottom
> task in the SST, and run everything else as the different SST tasks. In
> this case, one can alter the context of main() while keepeng everything
> else alive. This requires hacking of the stack frame.
>
>
> > One of the responses in this thread did make me think that you could
> > arrange the ISR to load the stack with just the right evil combination
> > of stuff such that when you hit the 'iret' instruction you'd be in
> > main() right before the while loop.
>
> That would be difficult if there are any other interrupts and tasks.
> Also it is very position dependent.

That's why I suggested hacking the stack frame to insert a call to a
signal handler instead. The signal handler has a well defined label, so
there are no position dependency issues. For maximum flexibility, the
handler could even be registered at run-time.

On a multitasking system, it is possible to rewrite the stack frame of
a particular task, rather than the interrupted one. You can even stack
multiple signals for the same task. A bitmask in the task struct could
be used to avoid duplicates.