Hey Wilhelm, That's a bug, the "interrupt" attribute is not being recognized by the backend. I have fixed it in https://github.com/llvm/llvm-project/commit/339b34266c1b54a9b5ff2f83cfb1da9cd8c9d90a Pull the latest LLVM and it should be fixed. On Tue, Mar 31, 2020 at 8:00 AM Wilhelm Meier <wilhelm.meier at hs-kl.de> wrote:> Hi Dylan, > > I used the following commandline: > > clang++ -Os -DF_OSC=20000000 -DF_CPU=20000000 --target=avr -I. > -I../include0 -I../../include0 -I../../../include0 -I../../include0/std > -I../include0/std -I../../../include0/std -I../../3rdparty/boost > -I/usr/avr/include -mmcu=atmega328p > /home/lmeier/Projekte/wmucpp/clang/bm00/bm00.cc -S -emit-llvm --output > bm00.ir > > Please find the IR attached in the file bm00.ir > > Thanks, > Wilhelm > > > Am 30.03.20 um 13:44 schrieb Dylan McKay: > > Hey Wilhelm, > > > > Could you post the LLVM IR generated from your C++ file? > > > > This can be achieved with 'clang -S -emit-llvm' > > > > Cheers > > > > On Sat, Mar 28, 2020 at 6:36 PM Wilhelm Meier <wilhelm.meier at hs-kl.de > > <mailto:wilhelm.meier at hs-kl.de>> wrote: > > > > Answering partly to myself there was a extern "C" missing. > > > > But the register pushes ans reti are still missing. > > > > Whats wrong? > > > > Am 28.03.20 um 06:26 schrieb Wilhelm Meier via llvm-dev: > > > Hi Dylan, > > > > > > the following code > > > > > > volatile uint8_t v1; > > > volatile uint8_t v2; > > > > > > __attribute__((interrupt)) void __vector_21(void) { > > > v2 = v1; > > > } > > > > > > produces in C mode: > > > > > > 00000092 <__vector_21>: > > > 92: 80 91 61 00 lds r24, 0x0061 ; 0x800061 <v1> > > > 96: 80 93 60 00 sts 0x0060, r24 ; 0x800060 > <__data_end> > > > 9a: 08 95 ret > > > > > > and in C++ mode: > > > > > > 00000074 <_Z11__vector_21v>: > > > 74: 80 91 60 00 lds r24, 0x0060 ; 0x800060 > <__data_end> > > > 78: 80 93 61 00 sts 0x0061, r24 ; 0x800061 <v2> > > > 7c: 08 95 ret > > > > > > So, in C++ mode it is not recognized as ISR due to name mangling. > > > > > > Furthermore there are no register push/pos and no reti. > > > > > > Whats wrong? > > > > > > Thanks. > > > > > > > > > Am 11.03.20 um 08:13 schrieb Dylan McKay: > > >> Here you go Wilhelm, > > >> > > >> https://github.com/dylanmckay/clang-avr-libc-interrupt-example > > >> > > >> > > >> > > >> On Thu, Mar 5, 2020 at 4:05 AM Wilhelm Meier > > <wilhelm.meier at hs-kl.de <mailto:wilhelm.meier at hs-kl.de> > > >> <mailto:wilhelm.meier at hs-kl.de <mailto:wilhelm.meier at hs-kl.de>>> > > wrote: > > >> > > >> Am 04.03.20 um 13:28 schrieb Dylan McKay: > > >> > > >> > > > >> > * *The C/C++ function needs to be declared with either > > the calling > > >> > convention avr-interrupt or > > avr-non-blocking-interrupt.* Skipping > > >> > this step will cause regular ret instructions to be > > emitted for > > >> > return-from-subroutine, instead of the required reti > > for interrupt > > >> > handlers. ISRs also have stricter requirements on which > > registers > > >> > must not be clobbered after execution, which the > > backend will > > >> handle > > >> > properly by restoring all clobbered registers in the > > interrupt > > >> > handler epilogue > > >> > * *The symbol names of the ISR function handlers must > > match those > > >> > referred to in avr-libc/avr-libgcc/crt*. This is > > because the ISR > > >> > table is specified in assembly inside the GCC AVR CRT. > > The way it > > >> > works is that the external symbol references in the CRT > > object > > >> files > > >> > are declared with an exotic linkage type that causes > > the linker to > > >> > skip linking of the symbols if they are undefined > > references. > > >> If you > > >> > chose a custom ISR table in a custom CRT or runtime > > library, you > > >> > would be free to choose ISR names as you pleased. > > >> > > > >> Thank you for your explanation. But I suspect I didn't get it > > right. Can > > >> you please provide an example? > > >> > > >> Thanks > > >> > > > _______________________________________________ > > > LLVM Developers mailing list > > > llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org> > > > https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev > > > > > >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20200331/ef657e4e/attachment-0001.html>
Hi Dylan, thank you. I'll be back with a test ... Wilhelm Am 31.03.20 um 08:06 schrieb Dylan McKay:> Hey Wilhelm, > > That's a bug, the "interrupt" attribute is not being recognized by the > backend. > > I have fixed it in > https://github.com/llvm/llvm-project/commit/339b34266c1b54a9b5ff2f83cfb1da9cd8c9d90a > > Pull the latest LLVM and it should be fixed. > > > On Tue, Mar 31, 2020 at 8:00 AM Wilhelm Meier <wilhelm.meier at hs-kl.de > <mailto:wilhelm.meier at hs-kl.de>> wrote: > > Hi Dylan, > > I used the following commandline: > > clang++ -Os -DF_OSC=20000000 -DF_CPU=20000000 --target=avr -I. > -I../include0 -I../../include0 -I../../../include0 -I../../include0/std > -I../include0/std -I../../../include0/std -I../../3rdparty/boost > -I/usr/avr/include -mmcu=atmega328p > /home/lmeier/Projekte/wmucpp/clang/bm00/bm00.cc -S -emit-llvm --output > bm00.ir <http://bm00.ir> > > Please find the IR attached in the file bm00.ir <http://bm00.ir> > > Thanks, > Wilhelm > > > Am 30.03.20 um 13:44 schrieb Dylan McKay: > > Hey Wilhelm, > > > > Could you post the LLVM IR generated from your C++ file? > > > > This can be achieved with 'clang -S -emit-llvm' > > > > Cheers > > > > On Sat, Mar 28, 2020 at 6:36 PM Wilhelm Meier > <wilhelm.meier at hs-kl.de <mailto:wilhelm.meier at hs-kl.de> > > <mailto:wilhelm.meier at hs-kl.de <mailto:wilhelm.meier at hs-kl.de>>> > wrote: > > > > Answering partly to myself there was a extern "C" missing. > > > > But the register pushes ans reti are still missing. > > > > Whats wrong? > > > > Am 28.03.20 um 06:26 schrieb Wilhelm Meier via llvm-dev: > > > Hi Dylan, > > > > > > the following code > > > > > > volatile uint8_t v1; > > > volatile uint8_t v2; > > > > > > __attribute__((interrupt)) void __vector_21(void) { > > > v2 = v1; > > > } > > > > > > produces in C mode: > > > > > > 00000092 <__vector_21>: > > > 92: 80 91 61 00 lds r24, 0x0061 ; 0x800061 <v1> > > > 96: 80 93 60 00 sts 0x0060, r24 ; 0x800060 > <__data_end> > > > 9a: 08 95 ret > > > > > > and in C++ mode: > > > > > > 00000074 <_Z11__vector_21v>: > > > 74: 80 91 60 00 lds r24, 0x0060 ; 0x800060 > <__data_end> > > > 78: 80 93 61 00 sts 0x0061, r24 ; 0x800061 <v2> > > > 7c: 08 95 ret > > > > > > So, in C++ mode it is not recognized as ISR due to name > mangling. > > > > > > Furthermore there are no register push/pos and no reti. > > > > > > Whats wrong? > > > > > > Thanks. > > > > > > > > > Am 11.03.20 um 08:13 schrieb Dylan McKay: > > >> Here you go Wilhelm, > > >> > > >> https://github.com/dylanmckay/clang-avr-libc-interrupt-example > > >> > > >> > > >> > > >> On Thu, Mar 5, 2020 at 4:05 AM Wilhelm Meier > > <wilhelm.meier at hs-kl.de <mailto:wilhelm.meier at hs-kl.de> > <mailto:wilhelm.meier at hs-kl.de <mailto:wilhelm.meier at hs-kl.de>> > > >> <mailto:wilhelm.meier at hs-kl.de > <mailto:wilhelm.meier at hs-kl.de> <mailto:wilhelm.meier at hs-kl.de > <mailto:wilhelm.meier at hs-kl.de>>>> > > wrote: > > >> > > >> Am 04.03.20 um 13:28 schrieb Dylan McKay: > > >> > > >> > > > >> > * *The C/C++ function needs to be declared with either > > the calling > > >> > convention avr-interrupt or > > avr-non-blocking-interrupt.* Skipping > > >> > this step will cause regular ret instructions to be > > emitted for > > >> > return-from-subroutine, instead of the required reti > > for interrupt > > >> > handlers. ISRs also have stricter requirements on > which > > registers > > >> > must not be clobbered after execution, which the > > backend will > > >> handle > > >> > properly by restoring all clobbered registers in the > > interrupt > > >> > handler epilogue > > >> > * *The symbol names of the ISR function handlers must > > match those > > >> > referred to in avr-libc/avr-libgcc/crt*. This is > > because the ISR > > >> > table is specified in assembly inside the GCC AVR > CRT. > > The way it > > >> > works is that the external symbol references in > the CRT > > object > > >> files > > >> > are declared with an exotic linkage type that causes > > the linker to > > >> > skip linking of the symbols if they are undefined > > references. > > >> If you > > >> > chose a custom ISR table in a custom CRT or runtime > > library, you > > >> > would be free to choose ISR names as you pleased. > > >> > > > >> Thank you for your explanation. But I suspect I didn't > get it > > right. Can > > >> you please provide an example? > > >> > > >> Thanks > > >> > > > _______________________________________________ > > > LLVM Developers mailing list > > > llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org> > <mailto:llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> > > > https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev > > > > > >
Hi Dylan, looks ok now. One thing: the ISR is now: __vector_21: ; @__vector_21 __vector_21$local: sei push r0 push r1 in r0, 63 push r0 clr r0 push r24 lds r24, v1 sts v2, r24 pop r24 pop r0 out 63, r0 pop r1 pop r0 reti There are unneccessary push/pops of r1 and r0 too, since the clr is useless ... GCC had the same problem but they made improvements. Thanks. Am 31.03.20 um 08:09 schrieb Wilhelm Meier via llvm-dev:> Hi Dylan, > > thank you. I'll be back with a test ... > > Wilhelm > > Am 31.03.20 um 08:06 schrieb Dylan McKay: >> Hey Wilhelm, >> >> That's a bug, the "interrupt" attribute is not being recognized by the >> backend. >> >> I have fixed it in >> https://github.com/llvm/llvm-project/commit/339b34266c1b54a9b5ff2f83cfb1da9cd8c9d90a >> >> Pull the latest LLVM and it should be fixed. >> >> >> On Tue, Mar 31, 2020 at 8:00 AM Wilhelm Meier <wilhelm.meier at hs-kl.de >> <mailto:wilhelm.meier at hs-kl.de>> wrote: >> >> Hi Dylan, >> >> I used the following commandline: >> >> clang++ -Os -DF_OSC=20000000 -DF_CPU=20000000 --target=avr -I. >> -I../include0 -I../../include0 -I../../../include0 -I../../include0/std >> -I../include0/std -I../../../include0/std -I../../3rdparty/boost >> -I/usr/avr/include -mmcu=atmega328p >> /home/lmeier/Projekte/wmucpp/clang/bm00/bm00.cc -S -emit-llvm --output >> bm00.ir <http://bm00.ir> >> >> Please find the IR attached in the file bm00.ir <http://bm00.ir> >> >> Thanks, >> Wilhelm >> >> >> Am 30.03.20 um 13:44 schrieb Dylan McKay: >> > Hey Wilhelm, >> > >> > Could you post the LLVM IR generated from your C++ file? >> > >> > This can be achieved with 'clang -S -emit-llvm' >> > >> > Cheers >> > >> > On Sat, Mar 28, 2020 at 6:36 PM Wilhelm Meier >> <wilhelm.meier at hs-kl.de <mailto:wilhelm.meier at hs-kl.de> >> > <mailto:wilhelm.meier at hs-kl.de <mailto:wilhelm.meier at hs-kl.de>>> >> wrote: >> > >> > Answering partly to myself there was a extern "C" missing. >> > >> > But the register pushes ans reti are still missing. >> > >> > Whats wrong? >> > >> > Am 28.03.20 um 06:26 schrieb Wilhelm Meier via llvm-dev: >> > > Hi Dylan, >> > > >> > > the following code >> > > >> > > volatile uint8_t v1; >> > > volatile uint8_t v2; >> > > >> > > __attribute__((interrupt)) void __vector_21(void) { >> > > v2 = v1; >> > > } >> > > >> > > produces in C mode: >> > > >> > > 00000092 <__vector_21>: >> > > 92: 80 91 61 00 lds r24, 0x0061 ; 0x800061 <v1> >> > > 96: 80 93 60 00 sts 0x0060, r24 ; 0x800060 >> <__data_end> >> > > 9a: 08 95 ret >> > > >> > > and in C++ mode: >> > > >> > > 00000074 <_Z11__vector_21v>: >> > > 74: 80 91 60 00 lds r24, 0x0060 ; 0x800060 >> <__data_end> >> > > 78: 80 93 61 00 sts 0x0061, r24 ; 0x800061 <v2> >> > > 7c: 08 95 ret >> > > >> > > So, in C++ mode it is not recognized as ISR due to name >> mangling. >> > > >> > > Furthermore there are no register push/pos and no reti. >> > > >> > > Whats wrong? >> > > >> > > Thanks. >> > > >> > > >> > > Am 11.03.20 um 08:13 schrieb Dylan McKay: >> > >> Here you go Wilhelm, >> > >> >> > >> https://github.com/dylanmckay/clang-avr-libc-interrupt-example >> > >> >> > >> >> > >> >> > >> On Thu, Mar 5, 2020 at 4:05 AM Wilhelm Meier >> > <wilhelm.meier at hs-kl.de <mailto:wilhelm.meier at hs-kl.de> >> <mailto:wilhelm.meier at hs-kl.de <mailto:wilhelm.meier at hs-kl.de>> >> > >> <mailto:wilhelm.meier at hs-kl.de >> <mailto:wilhelm.meier at hs-kl.de> <mailto:wilhelm.meier at hs-kl.de >> <mailto:wilhelm.meier at hs-kl.de>>>> >> > wrote: >> > >> >> > >> Am 04.03.20 um 13:28 schrieb Dylan McKay: >> > >> >> > >> > >> > >> > * *The C/C++ function needs to be declared with either >> > the calling >> > >> > convention avr-interrupt or >> > avr-non-blocking-interrupt.* Skipping >> > >> > this step will cause regular ret instructions to be >> > emitted for >> > >> > return-from-subroutine, instead of the required reti >> > for interrupt >> > >> > handlers. ISRs also have stricter requirements on >> which >> > registers >> > >> > must not be clobbered after execution, which the >> > backend will >> > >> handle >> > >> > properly by restoring all clobbered registers in the >> > interrupt >> > >> > handler epilogue >> > >> > * *The symbol names of the ISR function handlers must >> > match those >> > >> > referred to in avr-libc/avr-libgcc/crt*. This is >> > because the ISR >> > >> > table is specified in assembly inside the GCC AVR >> CRT. >> > The way it >> > >> > works is that the external symbol references in >> the CRT >> > object >> > >> files >> > >> > are declared with an exotic linkage type that causes >> > the linker to >> > >> > skip linking of the symbols if they are undefined >> > references. >> > >> If you >> > >> > chose a custom ISR table in a custom CRT or runtime >> > library, you >> > >> > would be free to choose ISR names as you pleased. >> > >> > >> > >> Thank you for your explanation. But I suspect I didn't >> get it >> > right. Can >> > >> you please provide an example? >> > >> >> > >> Thanks >> > >> >> > > _______________________________________________ >> > > LLVM Developers mailing list >> > > llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org> >> <mailto:llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> >> > > https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev >> > > >> > >> > _______________________________________________ > LLVM Developers mailing list > llvm-dev at lists.llvm.org > https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev >