>
> If I interpret you correct, it should be sufficient to use avr-ld/avr-libc?
Yes, this is correct.
I just compiled clang with avr-target enabled and all seems to
work> well. I did not check the startup-code and the placement / values of the
> ISR vector-table, but this should be ok also, when avr-ld is in use.
>
> How do I specify ISR-functions. The same way as in avr-gcc?
Two steps
- *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.
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, avr-objdump -St /usr/avr/lib/avr5/crtatmega328.o shows this
00000000 w .text 00000000 __vector_1> 00000000 w .text 00000000 __vector_2
> 00000000 w .text 00000000 __vector_3
> 00000000 w .text 00000000 __vector_4
> 00000000 w .text 00000000 __vector_5
> 00000000 w .text 00000000 __vector_6
> 00000000 w .text 00000000 __vector_7
> 00000000 w .text 00000000 __vector_8
> 00000000 w .text 00000000 __vector_9
> 00000000 w .text 00000000 __vector_10
> 00000000 w .text 00000000 __vector_11
>
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.
On Wed, Mar 4, 2020 at 11:37 PM Wilhelm Meier <wilhelm.meier at hs-kl.de>
wrote:
>
> Am 04.03.20 um 11:16 schrieb Dylan McKay:
> >
> > The new are of xmega3 architecture, which is already included. So
> this
> > should be simple.
> >
> > Where is the information about ISR-vector table, SRAM addresses
and
> so
> > on stored?
> >
> >
> > At the moment, this is not implemented in LLVM; these details are left
> > to the frontend. Clang/compiler-rt does not include the usual ISR
table
> > or AVR-specific startup routines to initialize SRAM from program
memory
> > - avr-clang-compiled executables must currently be linked with
> > avr-libc/libgcc. Users of the AVR-Rust frontend have implemented these
> > tables and routines in assembly in each source repository, or more
> > commonly just linked against avr-libc and GCC's AVR CRT libraries.
> > Ideally, we would provide our own implementation of these independent
of
> > the GCC/GNU ecosystem in somewhere like compiler-rt.
>
> If I interpret you correct, it should be sufficient to use avr-ld/avr-libc?
>
> I just compiled clang with avr-target enabled and all seems to work
> well. I did not check the startup-code and the placement / values of the
> ISR vector-table, but this should be ok also, when avr-ld is in use.
>
> How do I specify ISR-functions. The same way as in avr-gcc?
>
> Thanks!
>
>
> >
> > Hope that helps,
> >
> > Regards,
> > Dylan
> >
> > On Wed, Mar 4, 2020 at 11:10 PM Wilhelm Meier <wilhelm.meier at
hs-kl.de
> > <mailto:wilhelm.meier at hs-kl.de>> wrote:
> >
> > Thanks!
> >
> > The new are of xmega3 architecture, which is already included. So
> this
> > should be simple.
> >
> > Where is the information about ISR-vector table, SRAM addresses
and
> so
> > on stored?
> >
> > --
> > Wilhelm
> >
> > Am 04.03.20 um 11:03 schrieb Dylan McKay:
> > > Hey Wilhelm,
> > >
> > > This should be possible by editing the
'AVRDevices.td' [1]TableGen
> > > definitions to add an entry for the newer chip types. You
will
> need to
> > > instruct LLVM which features are available on the chip (such
as
> > extended
> > > LPM support), cross referencing with the instruction set
manual
> > for the
> > > AVR MCU you're adding to figure out what is allowed and
what is
> not.
> > >
> > > If there are newer instructions not yet supported by the AVR
> > backend, or
> > > if their are device-specific constraints not already handled
by the
> > > backend in its AVRDevices feature declarations, then you will
need
> to
> > > either extend the backend to support it, or declare the chip
with a
> > > lower level of support than is strictly required as a
workaround.
> > >
> > > Then after that, it should be possible to recompile the
backend and
> > > target the new chip type with 'llc -march=avr
-mcpu=tiny1614'. for
> > example.
> > >
> > > * [1] -
> > >
> >
>
https://github.com/llvm/llvm-project/blob/96fdc65dc4b19944079fa7f61ea52e4e0f999985/llvm/lib/Target/AVR/AVRDevices.td#L255
> > >
> > >
> > > Regards,
> > > Dylan
> > >
> > >
> > > On Wed, Mar 4, 2020 at 10:19 PM Wilhelm Meier via llvm-dev
> > > <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>>>
> > wrote:
> > >
> > > I'm beginning to use the AVR backend. I ran into the
problem,
> > that newer
> > > (tiny1, mega0) µC as a tiny1614 are not supported. How do
I
> > add these to
> > > the AVR backend?
> > >
> > > 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
> > >
> >
> > --
> > Wilhelm Meier
> > Vor dem Hirschberg 5
> > D-66459 Kirkel-Limbach
> > 0151-12414315
> >
>
> --
> Wilhelm Meier
> Vor dem Hirschberg 5
> D-66459 Kirkel-Limbach
> 0151-12414315
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20200305/aee49de9/attachment.html>