<div dir="ltr"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">If I interpret you correct, it should be sufficient to use avr-ld/avr-libc?</blockquote><div><br></div><div>Yes, this is correct.<br></div><div><br></div><div> <br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
I just compiled clang with avr-target enabled and all seems to work<br>
well. I did not check the startup-code and the placement / values of the<br>
ISR vector-table, but this should be ok also, when avr-ld is in use.<br><br>
How do I specify ISR-functions. The same way as in avr-gcc?</blockquote><div><br></div><div>Two steps</div><div><br></div><div><ul><li><b>The C/C++ function needs to be declared with either the calling convention avr-interrupt or avr-non-blocking-interrupt.</b> Skipping this step will cause regular <span style="font-family:monospace">ret</span> instructions to be emitted for return-from-subroutine, instead of the required <span style="font-family:monospace">reti</span> 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</li><li><b>The symbol names of the ISR function handlers must match those referred to in avr-libc/avr-libgcc/crt</b>. 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.</li></ul>To see what the ISRs function names are expected to be, either check out the avr-libc #define macros for declaring ISRs, as it exposes the final symbol names for the ISRs it generates, or you can find the symbol names via objdump directly from an AVR CRT object file, for example on my machine, <span style="font-family:monospace">avr-objdump -St /usr/avr/lib/avr5/crtatmega328.o</span> shows this</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div>00000000 w .text 00000000 __vector_1<br>00000000 w .text 00000000 __vector_2<br>00000000 w .text 00000000 __vector_3<br>00000000 w .text 00000000 __vector_4<br>00000000 w .text 00000000 __vector_5<br>00000000 w .text 00000000 __vector_6<br>00000000 w .text 00000000 __vector_7<br>00000000 w .text 00000000 __vector_8<br>00000000 w .text 00000000 __vector_9<br>00000000 w .text 00000000 __vector_10<br>00000000 w .text 00000000 __vector_11<br></div></blockquote><div><br></div><div>I suspect the avr-libc ISR macros will have AVR-GCC specific incantations that AVR-LLVM will refuse to link, probably a custom attribute, but YMMV.</div><div><br></div><div> <br></div>
</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Mar 4, 2020 at 11:37 PM Wilhelm Meier <<a href="mailto:wilhelm.meier@hs-kl.de">wilhelm.meier@hs-kl.de</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><br>
Am 04.03.20 um 11:16 schrieb Dylan McKay:<br>
> <br>
> The new are of xmega3 architecture, which is already included. So this<br>
> should be simple.<br>
> <br>
> Where is the information about ISR-vector table, SRAM addresses and so<br>
> on stored?<br>
> <br>
> <br>
> At the moment, this is not implemented in LLVM; these details are left<br>
> to the frontend. Clang/compiler-rt does not include the usual ISR table<br>
> or AVR-specific startup routines to initialize SRAM from program memory<br>
> - avr-clang-compiled executables must currently be linked with<br>
> avr-libc/libgcc. Users of the AVR-Rust frontend have implemented these<br>
> tables and routines in assembly in each source repository, or more<br>
> commonly just linked against avr-libc and GCC's AVR CRT libraries.<br>
> Ideally, we would provide our own implementation of these independent of<br>
> the GCC/GNU ecosystem in somewhere like compiler-rt.<br>
<br>
If I interpret you correct, it should be sufficient to use avr-ld/avr-libc?<br>
<br>
I just compiled clang with avr-target enabled and all seems to work<br>
well. I did not check the startup-code and the placement / values of the<br>
ISR vector-table, but this should be ok also, when avr-ld is in use.<br>
<br>
How do I specify ISR-functions. The same way as in avr-gcc?<br>
<br>
Thanks!<br>
<br>
<br>
> <br>
> Hope that helps,<br>
> <br>
> Regards,<br>
> Dylan<br>
> <br>
> On Wed, Mar 4, 2020 at 11:10 PM Wilhelm Meier <<a href="mailto:wilhelm.meier@hs-kl.de" target="_blank">wilhelm.meier@hs-kl.de</a><br>
> <mailto:<a href="mailto:wilhelm.meier@hs-kl.de" target="_blank">wilhelm.meier@hs-kl.de</a>>> wrote:<br>
> <br>
> Thanks!<br>
> <br>
> The new are of xmega3 architecture, which is already included. So this<br>
> should be simple.<br>
> <br>
> Where is the information about ISR-vector table, SRAM addresses and so<br>
> on stored?<br>
> <br>
> --<br>
> Wilhelm<br>
> <br>
> Am 04.03.20 um 11:03 schrieb Dylan McKay:<br>
> > Hey Wilhelm,<br>
> ><br>
> > This should be possible by editing the 'AVRDevices.td' [1]TableGen<br>
> > definitions to add an entry for the newer chip types. You will need to<br>
> > instruct LLVM which features are available on the chip (such as<br>
> extended<br>
> > LPM support), cross referencing with the instruction set manual<br>
> for the<br>
> > AVR MCU you're adding to figure out what is allowed and what is not.<br>
> ><br>
> > If there are newer instructions not yet supported by the AVR<br>
> backend, or<br>
> > if their are device-specific constraints not already handled by the<br>
> > backend in its AVRDevices feature declarations, then you will need to<br>
> > either extend the backend to support it, or declare the chip with a<br>
> > lower level of support than is strictly required as a workaround.<br>
> ><br>
> > Then after that, it should be possible to recompile the backend and<br>
> > target the new chip type with 'llc -march=avr -mcpu=tiny1614'. for<br>
> example.<br>
> ><br>
> > * [1] -<br>
> > <br>
> <a href="https://github.com/llvm/llvm-project/blob/96fdc65dc4b19944079fa7f61ea52e4e0f999985/llvm/lib/Target/AVR/AVRDevices.td#L255" rel="noreferrer" target="_blank">https://github.com/llvm/llvm-project/blob/96fdc65dc4b19944079fa7f61ea52e4e0f999985/llvm/lib/Target/AVR/AVRDevices.td#L255</a><br>
> ><br>
> ><br>
> > Regards,<br>
> > Dylan<br>
> ><br>
> ><br>
> > On Wed, Mar 4, 2020 at 10:19 PM Wilhelm Meier via llvm-dev<br>
> > <<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a> <mailto:<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>><br>
> <mailto:<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a> <mailto:<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>>>><br>
> wrote:<br>
> ><br>
> > I'm beginning to use the AVR backend. I ran into the problem,<br>
> that newer<br>
> > (tiny1, mega0) µC as a tiny1614 are not supported. How do I<br>
> add these to<br>
> > the AVR backend?<br>
> ><br>
> > Thanks!<br>
> > _______________________________________________<br>
> > LLVM Developers mailing list<br>
> > <a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a> <mailto:<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>><br>
> <mailto:<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a> <mailto:<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>>><br>
> > <a href="https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank">https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br>
> ><br>
> <br>
> -- <br>
> Wilhelm Meier<br>
> Vor dem Hirschberg 5<br>
> D-66459 Kirkel-Limbach<br>
> 0151-12414315<br>
> <br>
<br>
-- <br>
Wilhelm Meier<br>
Vor dem Hirschberg 5<br>
D-66459 Kirkel-Limbach<br>
0151-12414315<br>
</blockquote></div>