David,
Good points. As you probably are aware, avr-gcc interrupt
handlers are very special things. The generated code saves a
minimal set of processor state (i.e., registers) in entry.
Calling an external function forces the compiler to save
"everything" to preserve the avr-gcc "execution model"
(
https://gcc.gnu.org/wiki/avr-gcc), which, for example, assumes
that R1 always contains the constant zero.
For a C++ interrupt handler to work in all cases those rules need
to be headed. And, in-line assembly statements can easily "break"
the required execution model. Ask me how I know! :-)
Later AVR microcontrollers with hardware support for divide added
a status bit to SREG that needed to be saved/restored. That's one
of the reasons one needs to set the "machine type" correctly when
using avr-gcc.
Best regards,
Bruce D. Lightner
Lightner Engineering
La Jolla, California
lightner@lightner.net
https://www.linkedin.com/in/brucedlightner/
On 4/12/2021 6:49 AM, David Kelly wrote:
All of this might not be a bug at all but an undefined work around for deficiencies in C++ primitive functions in the avr-gcc support library? To prevent one from using?
In the early days of avr-gcc, just plain C, not all support primitive functions were reentrant. If memory serves me, math functions on longs were dangerous. That not all registers were stacked on entry to the interrupt handler (that would be costly) and the compiler (and support library) assumed some registers were free to use without preserving across function calls.
--
David Kelly N4HHE, dkelly@HiWAAY.net
============================================================
Whom computers would destroy, they must first drive mad.