similar to: Status of the AVR backend

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.

On Wed, Nov 16, 2016 at 5:11 PM, Dylan McKay via llvm-dev < llvm-dev at lists.llvm.org> wrote: > > - Support will be added to clang to support the backend (if it is > desired) > > +1. Are there patches for this already or do they need to be written? -- # Meador -------------- next part -------------- An HTML attachment was scrubbed... URL:

Hello. I was wondering if it is possible to implement placing RO variables within progmem sections. For now it is possible to just use [[gnu::progmem]] and read variables using assembly. My proposal is to: Use those variables as any other, without creating assembly. While reading them, compiler has all necessary knowledge where the variable is and can generate assembly Possible future

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

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

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

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

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> wrote: > Answering partly to myself there was a extern "C" missing. > > But the register pushes ans reti are still missing. > > Whats wrong? > > Am

Is there anything I can do about it? BTW: gcc is loosing the AVR backend, so I would assume, there will be a greater interest to this in llvm compared to the past. Thanks, Wilhelm Am 03.04.20 um 15:09 schrieb Wilhelm Meier via llvm-dev: > Should I create an issue in bugzilla for this? Just to be reminded ... > > Am 31.03.20 um 09:34 schrieb Wilhelm Meier via llvm-dev: >> Hi

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

Hello all, I have submitted and merged patches for most of the public modifications required for the AVR backend, and I am amount to start the process of adding the lib/Target/AVR directory piece by piece. As this will be a significant portion of code (~7000 lines), it should have a code owner. I have been working on the backend for the last year, maintaining it, overseeing contributions, and

I think you can probably treat that as a broad ‘no objection’ by the community. Are there any other active contributors to the AVR back end? David > On 27 Oct 2015, at 09:41, Dylan McKay via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > Ping. > > On Fri, Oct 23, 2015 at 4:04 PM, Dylan McKay <dylanmckay34 at gmail.com> wrote: > Hello all, > > I have

> > Should we just make it a normal target? > My only remaining reservation here - the generic DebugInfo tests, which presumably due to an unimplemented 16-bit branch somewhere deep in the llvm-objdump callstack. The AVR backend passes virtually all of the LLVM test suite but these when avr-unknown-unknown is set as the default target. It feels like the inclusion of ~80 XFAILs for these

Thanks Dylan, I am working on a backend which has mulhsu instruction that performs multiplication between signed and unsigned number and returns upper 32 bits into result register. I think I also need to write some code probably as you indicated to check signedness of the operands and based on that lower to mulhsu instruction. -Vivek On Mon, Feb 27, 2017 at 11:13 AM, Dylan McKay <me at

I maintain and develop an AVR backend for LLVM on GitHub <https://github.com/avr-llvm/llvm>. It has now progressed quite far, with the ability to compile most non-trivial programs unmodified (for example, the Arduino <https://www.arduino.cc/> suite. It has complete machine code/ELF support, also implementing the entire instruction set (as of 2015), and a functionally-complete assembly

To those interested in AVR backend additions to LLVM, the LLVM review tools "Phabricator" ( don't ask me to say that 3 times fast ), allows easy searching. Go to http://reviews.llvm.org/ and type in AVR in the search entry. This will give you a list of the commits, and resolutions. From my understanding ( NO Expert ), a large part of the skeleton code has been added. The leave

> On Feb 3, 2017, at 12:45 PM, Dylan McKay via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > The builder isn’t marked as experimental so I think the expectation is that people keep it green and contact the bot owner if they need help figuring out why their change makes it red. That said, it sounds a bit odd to have a non-experimental builder for an experimental backend. >

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!

How is the llvm-avr backend integration going ? Will it be functional ( experimental ) in the 3.8 release ? Will Clang recognize options for avr ? thanks. Allen -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20151218/be23dc42/attachment.html>

Exciting!!! > On Sep 29, 2015, at 17:03 , Hal Finkel via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > ----- Original Message ----- >> From: "Dylan McKay via llvm-dev" <llvm-dev at lists.llvm.org> >> To: llvm-dev at lists.llvm.org, "David Siegel" <agnat at me.com> >> Sent: Thursday, September 3, 2015 10:35:16 PM >>