avr-llvm-devel — Developers mailing list.

Re: [avr-llvm-devel] Need volunteers for avr-llvm?

[Stepan D. <stp...@na...>]

OK. I'll do then. Hope I'll present you first patches soon.
-Stepan.

John Myers wrote:
> Hi Stepan,
>
> We can definitely use some help. If I remember correctly, adding inline
> asm support was the next needed important step. So it would be great if
> you wanted to work on inline asm support.
>
>
> On Wed, Jun 5, 2013 at 3:33 AM, Stepan Dyatkovskiy <stp...@na...
> <mailto:stp...@na...>> wrote:
>
>     Hello guys.
>     Do you need some help? Inline asm? Is it in wishlist yet?
>
>     -Stepan
>
>

Re: [avr-llvm-devel] Need volunteers for avr-llvm?

[John M. <ato...@gm...>]

Hi Stepan,

We can definitely use some help. If I remember correctly, adding inline asm
support was the next needed important step. So it would be great if you
wanted to work on inline asm support.


On Wed, Jun 5, 2013 at 3:33 AM, Stepan Dyatkovskiy <stp...@na...>wrote:

> Hello guys.
> Do you need some help? Inline asm? Is it in wishlist yet?
>
> -Stepan
>

[avr-llvm-devel] Need volunteers for avr-llvm?

[Stepan D. <stp...@na...>]

Hello guys.
Do you need some help? Inline asm? Is it in wishlist yet?

-Stepan

Re: [avr-llvm-devel] Status of avr-llvm?

[John M. <ato...@gm...>]

Hi Rick,

>From what I understand avr-llvm should be able to compile most programs but
doesn't have inline asm support yet.
A complete toolchain also needs to be created which I actually just started
working on again this last weekend.

--John



On Mon, Apr 8, 2013 at 1:55 AM, Rick Mann <rm...@la...> wrote:

> Hi guys. Just wondering what the status of the port is. I'm a big fan of
> LLVM and LLDB, wondering if it's at all useable targeting AVR.
>
> Thanks!
>
> --
> Rick
>
>
>
>
>
> ------------------------------------------------------------------------------
> Minimize network downtime and maximize team effectiveness.
> Reduce network management and security costs.Learn how to hire
> the most talented Cisco Certified professionals. Visit the
> Employer Resources Portal
> http://www.cisco.com/web/learning/employer_resources/index.html
> _______________________________________________
> avr-llvm-devel mailing list
> avr...@li...
> https://lists.sourceforge.net/lists/listinfo/avr-llvm-devel
>

[avr-llvm-devel] Status of avr-llvm?

[Rick M. <rm...@la...>]

Hi guys. Just wondering what the status of the port is. I'm a big fan of LLVM and LLDB, wondering if it's at all useable targeting AVR.

Thanks!

-- 
Rick

Re: [avr-llvm-devel] Atmel Spaces?

[Borja F. <bor...@gm...>]

I'm ok with it.

Re: [avr-llvm-devel] Atmel Spaces?

[John M. <ato...@gm...>]

Does anyone else have an opinion on this?


On Mon, Dec 10, 2012 at 8:55 PM, Weddington, Eric <Eri...@at...
> wrote:

> Hi John,
>
> Sorry, I should have said in my original email that I consider it a hard
> requirement that the entire repository history must be maintained, if a
> move is decided upon.
>
> As to Atmel commitment to maintaining the website...
> 1. Atmel would not have released it, if there wasn't a commitment to
> maintain it...
> 2. ... And I'm in charge of Atmel Spaces, and have been working on getting
> it released. ;-)
>
> Eric Weddington
> Marketing Manager
> Open Source & Community
> Atmel
>
> > -----Original Message-----
> > From: John Myers [mailto:ato...@gm...]
> > Sent: Monday, December 10, 2012 6:56 PM
> > To: Weddington, Eric
> > Cc: avr...@li...
> > Subject: Re: [avr-llvm-devel] Atmel Spaces?
> >
> > I'm OK with switching over. I have a few concerns though. Can the SVN
> > commit history be transferred also?
> > I also wonder how committed Atmel will be to maintaining this website.
> >
> >
> > --John
> >
> >
> > On Mon, Dec 10, 2012 at 9:09 AM, Weddington, Eric
> > <Eri...@at...> wrote:
> >
> >
> >       Hi All,
> >
> >       I wanted to make a proposal, especially to the admins and
> developers
> > of the avr-llvm project.
> >
> >       We, being Atmel, recently released a new collaborative workspace
> > website, Atmel Spaces:
> >       http://spaces.atmel.com/
> >       These projects are all related to Atmel products. It has all the
> same
> > tools, and I think more, than SourceForge. With perhaps a little better
> > organization of them too.
> >
> >       What do you think of the idea of moving the avr-llvm project from
> > SourceForge to Atmel Spaces?
> >
> >       Please note that I'm making this proposal as just one of the
> members
> > of this project, and arguably, I haven't been as deeply involved in this
> > project as other members has been. I will definitely respect the decision
> > of this group, as I strongly believe that we (the developers) are all
> equal
> > stakeholders within this group.
> >
> >       Eric Weddington
> >
> >
> ---------------------------------------------------------------------
> > ---------
> >       LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial
> >       Remotely access PCs and mobile devices and provide instant support
> >       Improve your efficiency, and focus on delivering more value-add
> > services
> >       Discover what IT Professionals Know. Rescue delivers
> >       http://p.sf.net/sfu/logmein_12329d2d
> >       _______________________________________________
> >       avr-llvm-devel mailing list
> >       avr...@li...
> >       https://lists.sourceforge.net/lists/listinfo/avr-llvm-devel
> >
> >
>
>

Re: [avr-llvm-devel] Toolchain support needed!

[John M. <ato...@gm...>]

I'll have some time during my Christmas vacation to work on it.

On Thu, Dec 13, 2012 at 5:05 AM, Borja Ferrer <bor...@gm...> wrote:

> Hello John,
>
> I haven't tried anything further on this topic. Indeed, those 2 classes in
> clang you mentioned should be implemented to support our target, the other
> method is way to hacky. Do you have the time to take a look at this?
>
>
> 2012/12/13 John Myers <ato...@gm...>
>
>> Also, I've tried (a while ago) to set the include path and tell clang
>> where avr-gcc is using the *./configure* options but it didn't seem to
>> do anything for me.
>>
>
>

Re: [avr-llvm-devel] Toolchain support needed!

[Borja F. <bor...@gm...>]

Hello John,

I haven't tried anything further on this topic. Indeed, those 2 classes in
clang you mentioned should be implemented to support our target, the other
method is way to hacky. Do you have the time to take a look at this?

2012/12/13 John Myers <ato...@gm...>

> Also, I've tried (a while ago) to set the include path and tell clang
> where avr-gcc is using the *./configure* options but it didn't seem to do
> anything for me.
>

Re: [avr-llvm-devel] Toolchain support needed!

[John M. <ato...@gm...>]

Also, I've tried (a while ago) to set the include path and tell clang where
avr-gcc is using the *./configure* options but it didn't seem to do
anything for me.

Re: [avr-llvm-devel] Toolchain support needed!

[John M. <ato...@gm...>]

HI Borja,

Have you gone any farther with trying to setup a toolchain? It looks like
clang can just be installed using the same PREFIX that avr-gcc was
installed with in order to keep them in the same folder.

The include path is hard coded in clang (except for Windows and Linux
targets). So a quick and dirty way would be to make a patch to change it.
Clang has Driver & Toolchain classes which I think needs to be modified to
support an AVR target.


On Tue, Aug 28, 2012 at 3:24 PM, Borja Ferrer <bor...@gm...> wrote:

> Hello,
>
> With the latest changes, the backend is reaching the point where it can
> compile nearly any sort of code. One thing that is missing is support for
> inline asm which is heavily used in avr-libc, but apart from that it should
> be able to compile the rest. With a few tweaks i've been able to compile a
> 2200 line C file that stresses floating point calculations that produces
> around 22k instructions (C file -> S file)
>
> Now I'm getting more interested on getting a very basic toolchain working,
> Eric we'll need your help here. I've been able to build from a C file to a
> hex file a very basic main() function. avr-gcc is needed to produce the elf
> files and to drive the linker, so we'll have to stick with it for a while.
> The setup I have is messy because avr-gcc is in one folder with avr-libc
> and clang and llvm in another, so in order to get the toolchain with a
> decent setup both things should be in the same folder. Also included files
> default to the system's not the avr specific ones. Maybe others have tried
> it before, so i want to know how you did it or how hard it was, but in my
> case my first try was yesterday.
>
> Also I'm going to change how register-pairs are represented because avr-as
> can't understand what r29:r28 is. The llvm asm writer needs a bit of
> tweaking because avr-as can't understand some asm directives it produces.
>
> This is the cmd line i'm using to generate an object file: clang -O3
> test.c -o test.o -ccc-host-triple avr-generic-generic -ccc-gcc-name avr-gcc
> -mmcu=avr5
> notice that avr-gcc is passed so that clang can drive it once the .S file
> is generated.
>
> So try compiling a trivial main function to get the hex file generated,
> you'll need avr-copy (provided by binutils) to convert the elf file to hex,
> but that is easily handled by makefiles. Also people using windows try
> doing it aswell since I dont have a setup for it and I'm looking forward
> for it.
>
> Once we get the basic toolchain working, adding support for avr-libc and
> linking programs with its libraries should be much easier. I look forward
> for any help here!
>
>
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> avr-llvm-devel mailing list
> avr...@li...
> https://lists.sourceforge.net/lists/listinfo/avr-llvm-devel
>
>

Re: [avr-llvm-devel] Atmel Spaces?

[Weddington, E. <Eri...@at...>]

Hi John,

Sorry, I should have said in my original email that I consider it a hard requirement that the entire repository history must be maintained, if a move is decided upon.

As to Atmel commitment to maintaining the website...
1. Atmel would not have released it, if there wasn't a commitment to maintain it...
2. ... And I'm in charge of Atmel Spaces, and have been working on getting it released. ;-)

Eric Weddington
Marketing Manager
Open Source & Community
Atmel

> -----Original Message-----
> From: John Myers [mailto:ato...@gm...]
> Sent: Monday, December 10, 2012 6:56 PM
> To: Weddington, Eric
> Cc: avr...@li...
> Subject: Re: [avr-llvm-devel] Atmel Spaces?
> 
> I'm OK with switching over. I have a few concerns though. Can the SVN
> commit history be transferred also?
> I also wonder how committed Atmel will be to maintaining this website.
> 
> 
> --John
> 
> 
> On Mon, Dec 10, 2012 at 9:09 AM, Weddington, Eric
> <Eri...@at...> wrote:
> 
> 
> 	Hi All,
> 
> 	I wanted to make a proposal, especially to the admins and developers
> of the avr-llvm project.
> 
> 	We, being Atmel, recently released a new collaborative workspace
> website, Atmel Spaces:
> 	http://spaces.atmel.com/
> 	These projects are all related to Atmel products. It has all the same
> tools, and I think more, than SourceForge. With perhaps a little better
> organization of them too.
> 
> 	What do you think of the idea of moving the avr-llvm project from
> SourceForge to Atmel Spaces?
> 
> 	Please note that I'm making this proposal as just one of the members
> of this project, and arguably, I haven't been as deeply involved in this
> project as other members has been. I will definitely respect the decision
> of this group, as I strongly believe that we (the developers) are all equal
> stakeholders within this group.
> 
> 	Eric Weddington
> 
> 	---------------------------------------------------------------------
> ---------
> 	LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial
> 	Remotely access PCs and mobile devices and provide instant support
> 	Improve your efficiency, and focus on delivering more value-add
> services
> 	Discover what IT Professionals Know. Rescue delivers
> 	http://p.sf.net/sfu/logmein_12329d2d
> 	_______________________________________________
> 	avr-llvm-devel mailing list
> 	avr...@li...
> 	https://lists.sourceforge.net/lists/listinfo/avr-llvm-devel
> 
> 

Re: [avr-llvm-devel] Atmel Spaces?

[John M. <ato...@gm...>]

I'm OK with switching over. I have a few concerns though. Can the SVN
commit history be transferred also?
I also wonder how committed Atmel will be to maintaining this website.


--John

On Mon, Dec 10, 2012 at 9:09 AM, Weddington, Eric <Eri...@at...
> wrote:

> Hi All,
>
> I wanted to make a proposal, especially to the admins and developers of
> the avr-llvm project.
>
> We, being Atmel, recently released a new collaborative workspace website,
> Atmel Spaces:
> http://spaces.atmel.com/
> These projects are all related to Atmel products. It has all the same
> tools, and I think more, than SourceForge. With perhaps a little better
> organization of them too.
>
> What do you think of the idea of moving the avr-llvm project from
> SourceForge to Atmel Spaces?
>
> Please note that I'm making this proposal as just one of the members of
> this project, and arguably, I haven't been as deeply involved in this
> project as other members has been. I will definitely respect the decision
> of this group, as I strongly believe that we (the developers) are all equal
> stakeholders within this group.
>
> Eric Weddington
>
>
> ------------------------------------------------------------------------------
> LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial
> Remotely access PCs and mobile devices and provide instant support
> Improve your efficiency, and focus on delivering more value-add services
> Discover what IT Professionals Know. Rescue delivers
> http://p.sf.net/sfu/logmein_12329d2d
> _______________________________________________
> avr-llvm-devel mailing list
> avr...@li...
> https://lists.sourceforge.net/lists/listinfo/avr-llvm-devel
>

[avr-llvm-devel] Atmel Spaces?

[Weddington, E. <Eri...@at...>]

Hi All,

I wanted to make a proposal, especially to the admins and developers of the avr-llvm project.

We, being Atmel, recently released a new collaborative workspace website, Atmel Spaces:
http://spaces.atmel.com/
These projects are all related to Atmel products. It has all the same tools, and I think more, than SourceForge. With perhaps a little better organization of them too.

What do you think of the idea of moving the avr-llvm project from SourceForge to Atmel Spaces? 

Please note that I'm making this proposal as just one of the members of this project, and arguably, I haven't been as deeply involved in this project as other members has been. I will definitely respect the decision of this group, as I strongly believe that we (the developers) are all equal stakeholders within this group.

Eric Weddington

Re: [avr-llvm-devel] Toolchain support needed!

[Weddington, E. <Eri...@at...>]

Hi Borja,

I'm looking into it as we speak...

However, I will also be traveling to the Maker Faire New York this week. I think I'll have some extra "off-time" for this effort...

Eric

> -----Original Message-----
> From: Borja Ferrer [mailto:bor...@gm...]
> Sent: Saturday, September 22, 2012 10:05 AM
> To: Weddington, Eric
> Cc: avr...@li...
> Subject: Re: [avr-llvm-devel] Toolchain support needed!
> 
> ping
> 
> 
> 2012/9/9 Borja Ferrer <bor...@gm...>
> 
> 
> 	Hi Eric, welcome back!
> 
> 	Basically the situation is what I wrote in my previous email. We need
> to get a very basic toolchain working so we can complete the path from the
> .c to a .hex file. The backend should be able to compile any C code by now,
> except for new bugs and inline asm. If we're able to compile larger
> projects with the toolchain then we'll be able to detect more bugs and get
> a more reliable backend faster.
> 
> 	Currently, clang+llc (llc is the program that does the LLVM IR to AVR
> asm conversion) is able to compile C code to .S text asm files. The missing
> steps have to be done by avr-gcc, this is: generating the object files,
> linking them and generating hex files.
> 	My current setup is (under linux): an avr-gcc+avr-libc installation
> as described in the avr-libc manual, and a llvm installation, both in
> separate folders.
> 
> 	If you run this cmd line: clang -O3 test.c -o test.o -ccc-host-triple
> avr-generic-generic -ccc-gcc-name avr-gcc -mmcu=avr5
> 	clang drives llc to generate the .S file, then with the -ccc-gcc-name
> avr-gcc param it calls avr-gcc passing that new generated .S file so it can
> be converted to an object file with the help of the mmcu param indicating
> for what mcu we're compiling.
> 	avr-gcc has some logic inside where to drive the assembler and linker
> depending on the mmcu param it will call the linker with different options,
> for example the crt files involved. This is why for now we need avr-gcc,
> it's used as a driver for the linker and the assembler. Of course in the
> future we should be able to generate .o ELF files and an integrated
> assembler with llvm, but that will come later when we have a more mature
> backend.
> 
> 	One important thing is that clang has to use avr-libc's include files
> not the system's defaults, now when I include stdio.h it's using the linux
> header file, not the avr specific one. So obviously this has to be fixed,
> but we need to know first where these files are going to be placed in our
> toolchain, i guess as a quick hack using the -I param could do it, but in
> avr-gcc nobody uses it, so we shouldn't add more complexity to the cmd
> line.
> 
> 	If you need any other details, explanation or something I missed out
> let me know.
> 
> 
> 	2012/9/7 Weddington, Eric <Eri...@at...>
> 
> 
> 		Hi Borja!
> 
> 		Sorry to respond late to this email...
> 
> 		This is really exciting!
> 
> 		You said you need help in getting a basic toolchain working.
> Help me understand in detail, what you have, and where you want to be.
> 
> 		We need avr-gcc to run the assembler and linker. From avr-llvm,
> we have a compiler that will compile C to assembler. I would think that we
> would need to modify the avr-gcc specs to call the correct (new) executable
> for the compilation step.
> 
> 		If you can give me a few more details on your setup, then let's
> see where we can go with it. :-)
> 
> 		Eric
> 
> 
> 		> -----Original Message-----
> 		> From: Borja Ferrer [mailto:bor...@gm...]
> 		> Sent: Tuesday, August 28, 2012 4:24 PM
> 		> To: avr...@li...
> 		> Subject: [avr-llvm-devel] Toolchain support needed!
> 		>
> 		> Hello,
> 		>
> 		> With the latest changes, the backend is reaching the point
> where it can
> 		> compile nearly any sort of code. One thing that is missing is
> support for
> 		> inline asm which is heavily used in avr-libc, but apart from
> that it should be
> 		> able to compile the rest. With a few tweaks i've been able to
> compile a 2200
> 		> line C file that stresses floating point calculations that
> produces around 22k
> 		> instructions (C file -> S file)
> 		>
> 		> Now I'm getting more interested on getting a very basic
> toolchain working,
> 		> Eric we'll need your help here. I've been able to build from
> a C file to a hex
> 		> file a very basic main() function. avr-gcc is needed to
> produce the elf files
> 		> and to drive the linker, so we'll have to stick with it for a
> while. The setup
> 		> I have is messy because avr-gcc is in one folder with avr-
> libc and clang and
> 		> llvm in another, so in order to get the toolchain with a
> decent setup both
> 		> things should be in the same folder. Also included files
> default to the
> 		> system's not the avr specific ones. Maybe others have tried
> it before, so i
> 		> want to know how you did it or how hard it was, but in my
> case my first try
> 		> was yesterday.
> 		>
> 		> Also I'm going to change how register-pairs are represented
> because avr-as
> 		> can't understand what r29:r28 is. The llvm asm writer needs a
> bit of tweaking
> 		> because avr-as can't understand some asm directives it
> produces.
> 		>
> 		> This is the cmd line i'm using to generate an object file:
> clang -O3 test.c -o
> 		> test.o -ccc-host-triple avr-generic-generic -ccc-gcc-name
> avr-gcc -mmcu=avr5
> 		> notice that avr-gcc is passed so that clang can drive it once
> the .S file is
> 		> generated.
> 		>
> 		> So try compiling a trivial main function to get the hex file
> generated, you'll
> 		> need avr-copy (provided by binutils) to convert the elf file
> to hex, but that
> 		> is easily handled by makefiles. Also people using windows try
> doing it aswell
> 		> since I dont have a setup for it and I'm looking forward for
> it.
> 		>
> 		> Once we get the basic toolchain working, adding support for
> avr-libc and
> 		> linking programs with its libraries should be much easier. I
> look forward for
> 		> any help here!
> 
> 
> 
> 

Re: [avr-llvm-devel] Toolchain support needed!

[Borja F. <bor...@gm...>]

ping

2012/9/9 Borja Ferrer <bor...@gm...>

> Hi Eric, welcome back!
>
> Basically the situation is what I wrote in my previous email. We need to
> get a very basic toolchain working so we can complete the path from the .c
> to a .hex file. The backend should be able to compile any C code by now,
> except for new bugs and inline asm. If we're able to compile larger
> projects with the toolchain then we'll be able to detect more bugs and get
> a more reliable backend faster.
>
> Currently, clang+llc (llc is the program that does the LLVM IR to AVR asm
> conversion) is able to compile C code to .S text asm files. The missing
> steps have to be done by avr-gcc, this is: generating the object files,
> linking them and generating hex files.
> My current setup is (under linux): an avr-gcc+avr-libc installation as
> described in the avr-libc manual, and a llvm installation, both in separate
> folders.
>
> If you run this cmd line: clang -O3 test.c -o test.o -ccc-host-triple
> avr-generic-generic -ccc-gcc-name avr-gcc -mmcu=avr5
> clang drives llc to generate the .S file, then with the -ccc-gcc-name
> avr-gcc param it calls avr-gcc passing that new generated .S file so it can
> be converted to an object file with the help of the mmcu param indicating
> for what mcu we're compiling.
> avr-gcc has some logic inside where to drive the assembler and linker
> depending on the mmcu param it will call the linker with different options,
> for example the crt files involved. This is why for now we need avr-gcc,
> it's used as a driver for the linker and the assembler. Of course in the
> future we should be able to generate .o ELF files and an integrated
> assembler with llvm, but that will come later when we have a more mature
> backend.
>
> One important thing is that clang has to use avr-libc's include files not
> the system's defaults, now when I include stdio.h it's using the linux
> header file, not the avr specific one. So obviously this has to be fixed,
> but we need to know first where these files are going to be placed in our
> toolchain, i guess as a quick hack using the -I param could do it, but in
> avr-gcc nobody uses it, so we shouldn't add more complexity to the cmd line.
>
> If you need any other details, explanation or something I missed out let
> me know.
>
> 2012/9/7 Weddington, Eric <Eri...@at...>
>
> Hi Borja!
>>
>> Sorry to respond late to this email...
>>
>> This is really exciting!
>>
>> You said you need help in getting a basic toolchain working. Help me
>> understand in detail, what you have, and where you want to be.
>>
>> We need avr-gcc to run the assembler and linker. From avr-llvm, we have a
>> compiler that will compile C to assembler. I would think that we would need
>> to modify the avr-gcc specs to call the correct (new) executable for the
>> compilation step.
>>
>> If you can give me a few more details on your setup, then let's see where
>> we can go with it. :-)
>>
>> Eric
>>
>> > -----Original Message-----
>> > From: Borja Ferrer [mailto:bor...@gm...]
>> > Sent: Tuesday, August 28, 2012 4:24 PM
>> > To: avr...@li...
>> > Subject: [avr-llvm-devel] Toolchain support needed!
>> >
>> > Hello,
>> >
>> > With the latest changes, the backend is reaching the point where it can
>> > compile nearly any sort of code. One thing that is missing is support
>> for
>> > inline asm which is heavily used in avr-libc, but apart from that it
>> should be
>> > able to compile the rest. With a few tweaks i've been able to compile a
>> 2200
>> > line C file that stresses floating point calculations that produces
>> around 22k
>> > instructions (C file -> S file)
>> >
>> > Now I'm getting more interested on getting a very basic toolchain
>> working,
>> > Eric we'll need your help here. I've been able to build from a C file
>> to a hex
>> > file a very basic main() function. avr-gcc is needed to produce the elf
>> files
>> > and to drive the linker, so we'll have to stick with it for a while.
>> The setup
>> > I have is messy because avr-gcc is in one folder with avr-libc and
>> clang and
>> > llvm in another, so in order to get the toolchain with a decent setup
>> both
>> > things should be in the same folder. Also included files default to the
>> > system's not the avr specific ones. Maybe others have tried it before,
>> so i
>> > want to know how you did it or how hard it was, but in my case my first
>> try
>> > was yesterday.
>> >
>> > Also I'm going to change how register-pairs are represented because
>> avr-as
>> > can't understand what r29:r28 is. The llvm asm writer needs a bit of
>> tweaking
>> > because avr-as can't understand some asm directives it produces.
>> >
>> > This is the cmd line i'm using to generate an object file: clang -O3
>> test.c -o
>> > test.o -ccc-host-triple avr-generic-generic -ccc-gcc-name avr-gcc
>> -mmcu=avr5
>> > notice that avr-gcc is passed so that clang can drive it once the .S
>> file is
>> > generated.
>> >
>> > So try compiling a trivial main function to get the hex file generated,
>> you'll
>> > need avr-copy (provided by binutils) to convert the elf file to hex,
>> but that
>> > is easily handled by makefiles. Also people using windows try doing it
>> aswell
>> > since I dont have a setup for it and I'm looking forward for it.
>> >
>> > Once we get the basic toolchain working, adding support for avr-libc and
>> > linking programs with its libraries should be much easier. I look
>> forward for
>> > any help here!
>>
>>
>

Re: [avr-llvm-devel] Toolchain support needed!

[Borja F. <bor...@gm...>]

Hi Eric, welcome back!

Basically the situation is what I wrote in my previous email. We need to
get a very basic toolchain working so we can complete the path from the .c
to a .hex file. The backend should be able to compile any C code by now,
except for new bugs and inline asm. If we're able to compile larger
projects with the toolchain then we'll be able to detect more bugs and get
a more reliable backend faster.

Currently, clang+llc (llc is the program that does the LLVM IR to AVR asm
conversion) is able to compile C code to .S text asm files. The missing
steps have to be done by avr-gcc, this is: generating the object files,
linking them and generating hex files.
My current setup is (under linux): an avr-gcc+avr-libc installation as
described in the avr-libc manual, and a llvm installation, both in separate
folders.

If you run this cmd line: clang -O3 test.c -o test.o -ccc-host-triple
avr-generic-generic -ccc-gcc-name avr-gcc -mmcu=avr5
clang drives llc to generate the .S file, then with the -ccc-gcc-name
avr-gcc param it calls avr-gcc passing that new generated .S file so it can
be converted to an object file with the help of the mmcu param indicating
for what mcu we're compiling.
avr-gcc has some logic inside where to drive the assembler and linker
depending on the mmcu param it will call the linker with different options,
for example the crt files involved. This is why for now we need avr-gcc,
it's used as a driver for the linker and the assembler. Of course in the
future we should be able to generate .o ELF files and an integrated
assembler with llvm, but that will come later when we have a more mature
backend.

One important thing is that clang has to use avr-libc's include files not
the system's defaults, now when I include stdio.h it's using the linux
header file, not the avr specific one. So obviously this has to be fixed,
but we need to know first where these files are going to be placed in our
toolchain, i guess as a quick hack using the -I param could do it, but in
avr-gcc nobody uses it, so we shouldn't add more complexity to the cmd line.

If you need any other details, explanation or something I missed out let me
know.

2012/9/7 Weddington, Eric <Eri...@at...>

> Hi Borja!
>
> Sorry to respond late to this email...
>
> This is really exciting!
>
> You said you need help in getting a basic toolchain working. Help me
> understand in detail, what you have, and where you want to be.
>
> We need avr-gcc to run the assembler and linker. From avr-llvm, we have a
> compiler that will compile C to assembler. I would think that we would need
> to modify the avr-gcc specs to call the correct (new) executable for the
> compilation step.
>
> If you can give me a few more details on your setup, then let's see where
> we can go with it. :-)
>
> Eric
>
> > -----Original Message-----
> > From: Borja Ferrer [mailto:bor...@gm...]
> > Sent: Tuesday, August 28, 2012 4:24 PM
> > To: avr...@li...
> > Subject: [avr-llvm-devel] Toolchain support needed!
> >
> > Hello,
> >
> > With the latest changes, the backend is reaching the point where it can
> > compile nearly any sort of code. One thing that is missing is support for
> > inline asm which is heavily used in avr-libc, but apart from that it
> should be
> > able to compile the rest. With a few tweaks i've been able to compile a
> 2200
> > line C file that stresses floating point calculations that produces
> around 22k
> > instructions (C file -> S file)
> >
> > Now I'm getting more interested on getting a very basic toolchain
> working,
> > Eric we'll need your help here. I've been able to build from a C file to
> a hex
> > file a very basic main() function. avr-gcc is needed to produce the elf
> files
> > and to drive the linker, so we'll have to stick with it for a while. The
> setup
> > I have is messy because avr-gcc is in one folder with avr-libc and clang
> and
> > llvm in another, so in order to get the toolchain with a decent setup
> both
> > things should be in the same folder. Also included files default to the
> > system's not the avr specific ones. Maybe others have tried it before,
> so i
> > want to know how you did it or how hard it was, but in my case my first
> try
> > was yesterday.
> >
> > Also I'm going to change how register-pairs are represented because
> avr-as
> > can't understand what r29:r28 is. The llvm asm writer needs a bit of
> tweaking
> > because avr-as can't understand some asm directives it produces.
> >
> > This is the cmd line i'm using to generate an object file: clang -O3
> test.c -o
> > test.o -ccc-host-triple avr-generic-generic -ccc-gcc-name avr-gcc
> -mmcu=avr5
> > notice that avr-gcc is passed so that clang can drive it once the .S
> file is
> > generated.
> >
> > So try compiling a trivial main function to get the hex file generated,
> you'll
> > need avr-copy (provided by binutils) to convert the elf file to hex, but
> that
> > is easily handled by makefiles. Also people using windows try doing it
> aswell
> > since I dont have a setup for it and I'm looking forward for it.
> >
> > Once we get the basic toolchain working, adding support for avr-libc and
> > linking programs with its libraries should be much easier. I look
> forward for
> > any help here!
>
>

Re: [avr-llvm-devel] Toolchain support needed!

[Weddington, E. <Eri...@at...>]

Hi Borja!

Sorry to respond late to this email...

This is really exciting!

You said you need help in getting a basic toolchain working. Help me understand in detail, what you have, and where you want to be.

We need avr-gcc to run the assembler and linker. From avr-llvm, we have a compiler that will compile C to assembler. I would think that we would need to modify the avr-gcc specs to call the correct (new) executable for the compilation step.

If you can give me a few more details on your setup, then let's see where we can go with it. :-)

Eric

> -----Original Message-----
> From: Borja Ferrer [mailto:bor...@gm...]
> Sent: Tuesday, August 28, 2012 4:24 PM
> To: avr...@li...
> Subject: [avr-llvm-devel] Toolchain support needed!
> 
> Hello,
> 
> With the latest changes, the backend is reaching the point where it can
> compile nearly any sort of code. One thing that is missing is support for
> inline asm which is heavily used in avr-libc, but apart from that it should be
> able to compile the rest. With a few tweaks i've been able to compile a 2200
> line C file that stresses floating point calculations that produces around 22k
> instructions (C file -> S file)
> 
> Now I'm getting more interested on getting a very basic toolchain working,
> Eric we'll need your help here. I've been able to build from a C file to a hex
> file a very basic main() function. avr-gcc is needed to produce the elf files
> and to drive the linker, so we'll have to stick with it for a while. The setup
> I have is messy because avr-gcc is in one folder with avr-libc and clang and
> llvm in another, so in order to get the toolchain with a decent setup both
> things should be in the same folder. Also included files default to the
> system's not the avr specific ones. Maybe others have tried it before, so i
> want to know how you did it or how hard it was, but in my case my first try
> was yesterday.
> 
> Also I'm going to change how register-pairs are represented because avr-as
> can't understand what r29:r28 is. The llvm asm writer needs a bit of tweaking
> because avr-as can't understand some asm directives it produces.
> 
> This is the cmd line i'm using to generate an object file: clang -O3 test.c -o
> test.o -ccc-host-triple avr-generic-generic -ccc-gcc-name avr-gcc -mmcu=avr5
> notice that avr-gcc is passed so that clang can drive it once the .S file is
> generated.
> 
> So try compiling a trivial main function to get the hex file generated, you'll
> need avr-copy (provided by binutils) to convert the elf file to hex, but that
> is easily handled by makefiles. Also people using windows try doing it aswell
> since I dont have a setup for it and I'm looking forward for it.
> 
> Once we get the basic toolchain working, adding support for avr-libc and
> linking programs with its libraries should be much easier. I look forward for
> any help here!

Re: [avr-llvm-devel] Toolchain support needed!

[Borja F. <bor...@gm...>]

ping Eric.

2012/8/29 Borja Ferrer <bor...@gm...>

> Hello,
>
> With the latest changes, the backend is reaching the point where it can
> compile nearly any sort of code. One thing that is missing is support for
> inline asm which is heavily used in avr-libc, but apart from that it should
> be able to compile the rest. With a few tweaks i've been able to compile a
> 2200 line C file that stresses floating point calculations that produces
> around 22k instructions (C file -> S file)
>
> Now I'm getting more interested on getting a very basic toolchain working,
> Eric we'll need your help here. I've been able to build from a C file to a
> hex file a very basic main() function. avr-gcc is needed to produce the elf
> files and to drive the linker, so we'll have to stick with it for a while.
> The setup I have is messy because avr-gcc is in one folder with avr-libc
> and clang and llvm in another, so in order to get the toolchain with a
> decent setup both things should be in the same folder. Also included files
> default to the system's not the avr specific ones. Maybe others have tried
> it before, so i want to know how you did it or how hard it was, but in my
> case my first try was yesterday.
>
> Also I'm going to change how register-pairs are represented because avr-as
> can't understand what r29:r28 is. The llvm asm writer needs a bit of
> tweaking because avr-as can't understand some asm directives it produces.
>
> This is the cmd line i'm using to generate an object file: clang -O3
> test.c -o test.o -ccc-host-triple avr-generic-generic -ccc-gcc-name avr-gcc
> -mmcu=avr5
> notice that avr-gcc is passed so that clang can drive it once the .S file
> is generated.
>
> So try compiling a trivial main function to get the hex file generated,
> you'll need avr-copy (provided by binutils) to convert the elf file to hex,
> but that is easily handled by makefiles. Also people using windows try
> doing it aswell since I dont have a setup for it and I'm looking forward
> for it.
>
> Once we get the basic toolchain working, adding support for avr-libc and
> linking programs with its libraries should be much easier. I look forward
> for any help here!
>

[avr-llvm-devel] Toolchain support needed!

[Borja F. <bor...@gm...>]

Hello,

With the latest changes, the backend is reaching the point where it can
compile nearly any sort of code. One thing that is missing is support for
inline asm which is heavily used in avr-libc, but apart from that it should
be able to compile the rest. With a few tweaks i've been able to compile a
2200 line C file that stresses floating point calculations that produces
around 22k instructions (C file -> S file)

Now I'm getting more interested on getting a very basic toolchain working,
Eric we'll need your help here. I've been able to build from a C file to a
hex file a very basic main() function. avr-gcc is needed to produce the elf
files and to drive the linker, so we'll have to stick with it for a while.
The setup I have is messy because avr-gcc is in one folder with avr-libc
and clang and llvm in another, so in order to get the toolchain with a
decent setup both things should be in the same folder. Also included files
default to the system's not the avr specific ones. Maybe others have tried
it before, so i want to know how you did it or how hard it was, but in my
case my first try was yesterday.

Also I'm going to change how register-pairs are represented because avr-as
can't understand what r29:r28 is. The llvm asm writer needs a bit of
tweaking because avr-as can't understand some asm directives it produces.

This is the cmd line i'm using to generate an object file: clang -O3 test.c
-o test.o -ccc-host-triple avr-generic-generic -ccc-gcc-name avr-gcc
-mmcu=avr5
notice that avr-gcc is passed so that clang can drive it once the .S file
is generated.

So try compiling a trivial main function to get the hex file generated,
you'll need avr-copy (provided by binutils) to convert the elf file to hex,
but that is easily handled by makefiles. Also people using windows try
doing it aswell since I dont have a setup for it and I'm looking forward
for it.

Once we get the basic toolchain working, adding support for avr-libc and
linking programs with its libraries should be much easier. I look forward
for any help here!

Re: [avr-llvm-devel] Regression tests

[Borja F. <bor...@gm...>]

Any updates about those tests?

2012/7/17 Borja Ferrer <bor...@gm...>

> Nicklas don't your local repo to the latest revision because with the
> introduction of the earlyclobber flag you won't be able to test what I said
> in the previous mail. Once you have those tests ready then update to see if
> they sitll fail.
>
>
> 2012/7/13 Borja Ferrer <bor...@gm...>
>
>> Nicklas see if you can try to come up with a test that exposes the
>> undefined behaviour of predec and postinc instructions, in the instruction
>> set pdf you have the details. I wan't to see if that test will pass with a
>> patch that I have prepared.
>>
>>
>> 2012/7/9 Borja Ferrer <bor...@gm...>
>>
>>> I've commited the fix. Thanks for reporting it!
>>>
>>> Please add this test to the ones you're currently writing so it can be
>>> caught in the future.
>>>
>>
>>
>

Re: [avr-llvm-devel] Regression tests

[Borja F. <bor...@gm...>]

Nicklas don't your local repo to the latest revision because with the
introduction of the earlyclobber flag you won't be able to test what I said
in the previous mail. Once you have those tests ready then update to see if
they sitll fail.

2012/7/13 Borja Ferrer <bor...@gm...>

> Nicklas see if you can try to come up with a test that exposes the
> undefined behaviour of predec and postinc instructions, in the instruction
> set pdf you have the details. I wan't to see if that test will pass with a
> patch that I have prepared.
>
>
> 2012/7/9 Borja Ferrer <bor...@gm...>
>
>> I've commited the fix. Thanks for reporting it!
>>
>> Please add this test to the ones you're currently writing so it can be
>> caught in the future.
>>
>
>

Re: [avr-llvm-devel] Regression tests

[Borja F. <bor...@gm...>]

Nicklas see if you can try to come up with a test that exposes the
undefined behaviour of predec and postinc instructions, in the instruction
set pdf you have the details. I wan't to see if that test will pass with a
patch that I have prepared.

2012/7/9 Borja Ferrer <bor...@gm...>

> I've commited the fix. Thanks for reporting it!
>
> Please add this test to the ones you're currently writing so it can be
> caught in the future.
>

Re: [avr-llvm-devel] Issues Building From Source

[Stefan L. <ton...@us...>]

>> However, I still get an get an error during the build(*):
>>
> It looks like its trying to build for the host instead of the AVR target.
> What is your configure options set to?

./configure --disable-optimized --enable-targets=avr

> Is this error part of the LLVM build or are you trying to do a make in
> projects/compiler-rt ?
It's part of the LLVM build (just "make" in the llvm directory), but
since I did have compiler-rt checked out in the projects folder as
described in "Getting Started: Building and Running Clang"
(http://clang.llvm.org/get_started.html) it got built too. The tests
were run with "make check" in the llvm\test directory.

I've now tried building without checking out compiler-rt, since you
made it sound like it wasn't crucial for the AVR target, and the build
came through without any errors.
Thanks for the help.

Re: [avr-llvm-devel] Issues Building From Source

[John M. <ato...@gm...>]

Hi Stefan,

However, I still get an get an error during the build(*):
>
>
It looks like its trying to build for the host instead of the AVR target.
What is your configure options set to?
Is this error part of the LLVM build or are you trying to do a make in
projects/compiler-rt ?

When only building for the AVR target I don't believe compiler-rt is of
much use yet (other then Apple's Blocks feature).
There aren't any patches or code for AVR optimized library functions.
So I'm guessing not much of the compiler-rt library should be included by
the build system.

--John