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
light...@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, dke...@hiwaay.net
============================================================
Whom computers would destroy, they must first drive mad.
