[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[avr-libc-dev] Re: gcc's avr implementation does not appear to be interr
[avr-libc-dev] Re: gcc's avr implementation does not appear to be interrupt safe!
Wed, 19 Jan 2005 14:29:49 -0500
Yup, or eliminate the r1 = 0 assumption and let the compiler do it's thing.
Which would seem to eliminate many of the present subtleties associated with
interrupt calling conventions, one which I didn't notice clearly documented:
is that compiled functions can only be called safely from a pure assembly
coded interrupt routines if that routine first pushes, clears, and then
subsequently pops r1 prior to any direct or indirect compiled function
calls, as although the routine may not utilize r1 itself, compiled functions
will presume it's 0, although it may not be (which the C interrupt routine
wrapper would have done for you), although acknowledge that it's subtly
> From: "E. Weddington" <address@hidden>
>> Paul Schlie wrote:
>> Well, good thing I didn't, as it is safe iff the interrupt routine
>> prolog/epilogue is generated by GCC, as it does properly recognize that
>> r1 may not be 0 at the point of interruption then pushes, clears, and
>> then subsequently pops r1; so it's only assembly routines which were not
>> declared to gcc as being so that would experience problems.
>> (sorry for the false alarm, noticed the problem in interrupt routines which
>> were not declared as such to gcc.)
> And that's why when somebody is writing assembler routines to interface
> with C routines they have to be aware of the ABI, which is described in
> a FAQ entry in the avr-libc user manual:
>>> From: Paul Schlie <address@hidden>
>>> Eric, the reason I posted it to only you two, was that it's likely a
>>> sensitive observation; where I thought you might want to have a chance
>>> to confirm or correct the observation prior to it being more broadly
>>> stated that gcc for avr including winavr is inherently unsafe to use in
>>> many circumstances.