Re: [avr-libc-dev] Re: gcc's avr implementation does not appear to be interrupt safe!

[Paul Schlie]

> From: Galen Seitz <address@hidden>
> 
> Maybe I'm missing something, but it seems to me that any multitasking
> system is required to preserve most, if not all, registers when changing
> context.  This would include R1.  I don't think context switch code should
> be making assumptions about register usage.

(yes, as long as any newly invoked compiled code has r1 == 0 initially)

As presently structured:

- all compiled code presumes r1 == 0 (unless it modifies it itself).

- if it modifies it itself, and receives an interrupt during that interval,
  it will rely on that value being as it had left it, no problem.

- if the interrupt routine is not itself wrapped in the compiler's interrupt
  routine prologue/epilogue code, which knows that r1 may not == 0,
  therefore not only saves it's context but also clears it prior to
  proceeding, as otherwise any subsequently called compiled functions will
  falsely presume it's 0, as it may not be.

- if a task-switching-kernel is written in assembler and/or invoked without
  first having r1's state saved and cleared, it will have to do it itself
  prior to invoking any non-previously executing compiled code which
  presumes r1 == 0; but previously executing code, as you've noted,
  will/should resume execution using it's previously saved context, which
  although may have been interrupted with r1 != 0, it needed to began life
  that way.

(the concern arose when calling compiled code from a raw assembly interrupt
 handler which although didn't touch r1 itself, discovered it needed to
 save/clear r1 prior to making any calls to compiled routines for them to
 be reliable, as they do presume/require r1 == 0, but don't initialize it
 themselves. Which was somewhat of an insidious bug in my code, as it worked
 fine 99.99... % of the time, but learned what was necessary the hard way.)