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