similar to: [LLVMdev] AVR back end

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

Thank you for both of your input. Yes, I try to cross-compile for AVR, the simple ATMEGA328P used in every Arduino Uno. My main motivation being that I hope to be able to use a couple of STL containers, <functional> and <type_traits> on the MCU. Not sure though if this can be reached by going via the clang route. Getting back to the compilation: when I run clang with both both

Hi, I'd like to modify MachineBasicBlock contents within a MachineFunctionPass on the basis of how many CPU cycles the assembly instructions corresponding to the MBB take. I'm using the AVR backend and the number of CPU cycles every AVR assembly operation takes is openly available. Is there any straightforward way of getting the opcode mnemonics corresponding to a MachineInstr? I've

Hi! I think it is a great idea. The DS80C400 needs external memory, and/or flash. It have the Ethernet integrated, but it is really slow (it is 8051 architecture), and yes, I know it can go up ti 75Mhz, but only gives 18MIPS max. I would use ATmega128 from atmel (16MIPS at only 16Mhz), take a look at: http://www.ethernut.de (project using mega128 with Ethernet, includes schematics). It

Hi, What is the Cmake equivalent to configures target option [ ./configure --target=avr-atmel-none] ? --John -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20120710/5405f54b/attachment.html>

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

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

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

> > 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! 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.

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

I think this is broken in at least one place when legalising the DAG. This llvm ir: %3 = call { i16, i1 } @llvm.umul.with.overflow.i16(i16 %2, i16 11) Fails to lower correctly on AVR but the problem is, unfortunately, not just coming from the AVR Target code and I am not sure it can be cleanly fixed just there. (But I would be very happy to be proved wrong as I'm very new to this.) The above

Hi everyone, I've been wondering how to correctly build clang/LLVM for the AVR target architecture. Unfortunately documentation is very scarce (or outdated or I didn't find it) and while I've been able to build clang/LLVM for AVR I'm still falling short of compiling an actual binary for the MCU. Here are the steps I've undertaken so far: git clone

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>

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

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!

Hi Martin, > The CPU that I am targeting is VLIW with no hardware interlocking (the next instruction does not wait for the previous to complete). This leads to fairly complex scheduling, but can be generally accommodated well in LLVM. Thanks for sharing your usecase about instruction scheduling, I am learning Instruction Selector by reading ARM and AMDGPU target's source code, then

Greetings. I have a Tripp-Lite AVR-900U that I am trying to get work with NUT. (I rather naively bought the thing assuming that since NUT worked with the AVR-750U, that the same would be so of this model.) Here's what I've got so far: # upsdrvctl start Network UPS Tools - UPS driver controller 2.4.3 Network UPS Tools - Generic HID driver 0.34 (2.4.3) USB communication driver 0.31 This

[the mailing list you want is nut-upsuser.] On Mon, Aug 3, 2009 at 8:05 AM, Blagovest Kolenichev wrote: > Hi, all > > I had fail to find in the supported hardware page > > http://www.networkupstools.org/compat/stable.html > > support for "NOVA AVR 625", but see that "NOVA AVR 600 Serial" > is supported. Can you tell us is there a big difference between

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