Re: [avr-gcc-list] RFC: Speeding up small ISRs: PR20296

[Erik Christiansen]

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 address@hidden $^ > 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