Re: RFC: Speeding up small ISRs: PR20296

On 06/19/2017 10:48 PM, Erik Christiansen wrote:
> On 15.06.17 14:43, Georg-Johann Lay wrote:
>> https://gcc.gnu.org/PR20296
>>
>> is about speeding up "small" ISRs, and is open for 12 years now...
>>
>> Anyone familiar with avr-gcc knows that a fix would be high effort and risk,
>> and that's the major reason for why PR20296 is still open (and even
>> classified "suspended").
> ...
> 
> Johann, I'll be off the net for about a week from late tonight (GMT+10),
> so unfortunately not able to respond immediately on any complications
> arising. (They're always there, in anything which has remained unsolved
> for 12 years.)
> 
> A low-effort solution seems needed here, because it is so easy to avoid
> all the complexity by just replacing the long-winded ugly and convoluted
> 'C' in PR20296:
> 
> void SIG_PIN_CHANGE0 (void) __attribute__ ((signal)); void SIG_PIN_CHANGE0 (void)
> {
>    (*(volatile unsigned char *)((0x12) + 0x20)) |= 1;
> }
> 
> with a simple and elegant assembler file:
> 
>>>
>     .func SIG_PIN_CHANGE0
>     .global SIG_PIN_CHANGE0
> 
>     sbi 0x12, 0
>     reti
> <<
> 
> put it through gas, and just link its .o file in with all those produced
> from 'C'. All finished and done - without any hassles or toolchain
> modification.
> 
> Call me pragmatic, but I see two classes of user: those who don't
> understand the two lines of assembler, and won't know or fuss about the
> inefficient gcc overprotection; and those who do know enough to fuss,
> and can therefore type two lines of assembler, a global declaration, and
> add to their makefile a:
> 
> %.o: %.s
>     $(AS) -I$(INC_DIR) $(ASFLAGS) -o $(OBJDIR)/$@ $<
> 
> To produce the ISR .o file.
> 
> If their linking makefile target uses *.o, then the new one is linked
> automatically. I tend to list object files explicitly, as I omit some
> during development, e.g.:
> 
> target: init.o encoder.o lcd.o os.o keyboard.o ui.o mathlib.o
>        ( cd $(OBJDIR) ; $(CC) $(LDFLAGS) $(CFLAGS) -o [email protected] $^ > map )
>        ...
> 
> Either way, there's not much to it, and there is never any unexpected
> code padding. That's a big part of the reason why it seems that only a
> minimally intrusive (and labour intensive) toolchain effort is
> warranted.
> 
> Erik

 > cat avr-sig.c
#include <io.h>
#include <interrupt.h>

ISR(PCINT0_vect,ISR_NAKED ){
   (*(volatile unsigned char *)((0x12) + 0x20)) |= 1;
   reti();
}


 > avr-gcc -O3 -mmcu=atmega165 -S avr-sig.c  -I /usr/lib/avr/include/avr/

 > cat avr-sig.s
         .file   "avr-sig.c"
__SP_H__ = 0x3e
__SP_L__ = 0x3d
__SREG__ = 0x3f
__tmp_reg__ = 0
__zero_reg__ = 1
         .text
.global __vector_2
         .type   __vector_2, @function
__vector_2:
/* prologue: naked */
/* frame size = 0 */
/* stack size = 0 */
.L__stack_usage = 0
         sbi 0x12,0
/* #APP */
  ;  6 "avr-sig.c" 1
         reti
  ;  0 "" 2
/* epilogue start */
/* #NOAPP */
         .size   __vector_2, .-__vector_2
         .ident  "GCC: (GNU) 4.9.2"