Re: [avr-gcc-list] use of GOTO statement

[Bernard Fouché]

Maybe Juan is designing his own tiny os and then needs to write a 
scheduler that gives control in turn to each process? Or wants to 
provide some warranty on the time taken by a system to react to an event 
with a reaction too big to be run only as an interrupt? In such case it 
may be necessary to be able to alter the return address of an interrupt, 
making it functionning as the scheduler core.

Anyway there are tiny os's that should do that and I would look in that 
way if I were looking for such a feature. But I expect that in this case 
the CPU is made to point at another stack frame (one for each 
process/task) with some asm code. Or maybe with setjmp()/longjmp() ?

Bernard

address@hidden wrote:

> *If you want the non-interrupt software to change what it is executing 
> based on getting/processing an interrupt, then the C language goto is 
> not the correct concept. The common way to do what you want is to 
> implement a finite state machine in the non-interrupt section of your 
> system software. The interrupt service routines set flags or other 
> mechanisms and exit the interrupt as usual. The non-interrupt code 
> looks at this variable and branches accordingly. The non-interrupt 
> level code also disables interrupts briefly while altering this 
> variable to provide mutual exclusion with an interrupt routine which 
> may alter this variable. An Interrupt routine could alter the return 
> PC, but this is poor form and will very likely lead to an unreliable 
> design.*