avr-llvm-devel — Developers mailing list.

Re: [avr-llvm-devel] [FYI] WebSVN installed

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

 

> -----Original Message-----
> From: Josef Eisl [mailto:za...@za...] 
> Sent: Sunday, November 29, 2009 8:52 AM
> To: avr...@li...
> Subject: [avr-llvm-devel] [FYI] WebSVN installed
> 
> Hello,
> 
> I've installed WebSVN on our projects website:
> http://avr-llvm.sourceforge.net/websvn/
> 
> It is prettier that the ViewVC (in my eyes) and might be useful. As it
> is not available as hosted app I've 'installed' it by hand.

Thanks for doing this! :-)

Re: [avr-llvm-devel] current status and future direction oftheavr-llvm project

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

 

> -----Original Message-----
> From: Josef Eisl [mailto:za...@za...] 
> Sent: Sunday, November 29, 2009 9:06 AM
> To: avr...@li...
> Subject: Re: [avr-llvm-devel] current status and future 
> direction oftheavr-llvm project
> 
> > Or an alternative is that we (one of us at least) use those 
> specific versions and regenerate configure and commit that. I 
> worry about patching configure. I don't have a problem with 
> regenerating it.
> 
> I've the required versions installed and can commit the updated
> configure file. But, to be honest, I don't see why replacing configure
> is better than patching it or am I missing something?
> Anyway I think this is no big deal. Both ways are ok for me  :) .

It's more of a philosophical point: configure is a generated file, and typically not something that you patch like source code. We should regenerate the file in full. When we do the commit, the revision control system will take care of figuring out the diff.

But really it sounds like we'll work this out. I'm not worried.

Re: [avr-llvm-devel] new directory structure and documentationsuggestion [RFC]

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

Regarding directory structure: I'm not attached to any particular structure. However, I would like to make sure that we make it easy on ourselves when we merge upstream to LLVM. I trust that you'll make the right decisions regarding the structure. So just feel free to make the changes as you see fit.

Regarding documentation: Again, I'm not attached to any particular layout or method. I do think that you should post your early drafts; they don't have to be perfect in order to have something that we can all work with. My only recommendation is to not spend a whole lot of time on the formatting of the documentation. Most of our documentation should be eventually migrated upstream to the LLVM project.

Thanks for taking the time to do all of this. It's really appreciated.

Eric

> -----Original Message-----
> From: Josef Eisl [mailto:za...@za...] 
> Sent: Sunday, November 29, 2009 7:59 AM
> To: avr...@li...
> Subject: [avr-llvm-devel] new directory structure and 
> documentationsuggestion [RFC]
> 
> Hello,
> 
> I would like to suggest another change (hopefully the last one) to our
> svn structure.
> 
> Sooner or later we will need do customize either the llvm-gcc or the
> clang front-end (or both) and I think we should prepare the svn
> structure now. The new structure should be similar to the llvm svn
> repository to make things easier.
> 
> Variant 1: just move the current structure into a new llvm 
> subfolder and
> create folders for the front-ends.
> 
> variant1
> |-- cfe
> |   |-- branches
> |   |-- tags
> |   `-- trunk
> |-- llvm
> |   |-- branches
> |   |-- tags
> |   `-- trunk
> |       |-- AVR
> |       |-- patches
> |       `-- testcases
> |-- llvm-gcc-4.2
> |   |-- branches
> |   |-- tags
> |   `-- trunk
> `-- website
>     |-- branches
>     |-- tags
>     `-- trunk
>         `-- docs
> 
> The second variant is very similar but the AVR folder is moved to
> trunk/lib/Target/AVR. The path is getting a little bit longer 
> but it is
> more obvious where the AVR folder fits in into the llvm source tree.
> 
> variant2
> |-- cfe
> |   |-- branches
> |   |-- tags
> |   `-- trunk
> |-- llvm
> |   |-- branches
> |   |-- tags
> |   `-- trunk
> |       |-- lib
> |       |   `-- Target
> |       |       `-- AVR
> |       |-- patches
> |       `-- testcases
> |-- llvm-gcc-4.2
> |   |-- branches
> |   |-- tags
> |   `-- trunk
> `-- website
>     |-- branches
>     |-- tags
>     `-- trunk
>         `-- docs
> 
> 
> The other idea is about documentation. Like in LLVM we could create a
> website folder and use html files for documentation and maybe put them
> on http://avr-llvm.sourceforge.net.
> I am thinking of docs about:
> 
> - Getting Started: how to prepare the llvm source tree and 
> compile llvm
> with avr support
> - Developer Guide: Commit rules, Coding Standards, etc
> - Testing: test cases, test framework, etc
> 
> And maybe a front page with links to the ML and the other documents.
> 
> I've some early drafts for these documents and will post the for
> discussion if we decide to go this way.
> 
> All comments are very welcome.
> 
> BR
> Josef
> 
> --------------------------------------------------------------
> ----------------
> Let Crystal Reports handle the reporting - Free Crystal 
> Reports 2008 30-Day 
> trial. Simplify your report design, integration and 
> deployment - and focus on 
> what you do best, core application coding. Discover what's new with
> Crystal Reports now.  http://p.sf.net/sfu/bobj-july
> _______________________________________________
> avr-llvm-devel mailing list
> avr...@li...
> https://lists.sourceforge.net/lists/listinfo/avr-llvm-devel
> 

Re: [avr-llvm-devel] new directory structure and documentation suggestion [RFC]

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

I vote for using varient1.
sourceforge has hosted apps like MediaWiki which could be used for
documentation.
I've never used any of them so I don't know if it would be any easier/better
to use.

On Sun, Nov 29, 2009 at 6:59 AM, Josef Eisl <za...@za...> wrote:

> Hello,
>
> I would like to suggest another change (hopefully the last one) to our
> svn structure.
>
> Sooner or later we will need do customize either the llvm-gcc or the
> clang front-end (or both) and I think we should prepare the svn
> structure now. The new structure should be similar to the llvm svn
> repository to make things easier.
>
> Variant 1: just move the current structure into a new llvm subfolder and
> create folders for the front-ends.
>
> variant1
> |-- cfe
> |   |-- branches
> |   |-- tags
> |   `-- trunk
> |-- llvm
> |   |-- branches
> |   |-- tags
> |   `-- trunk
> |       |-- AVR
> |       |-- patches
> |       `-- testcases
> |-- llvm-gcc-4.2
> |   |-- branches
> |   |-- tags
> |   `-- trunk
> `-- website
>    |-- branches
>    |-- tags
>    `-- trunk
>        `-- docs
>
> The second variant is very similar but the AVR folder is moved to
> trunk/lib/Target/AVR. The path is getting a little bit longer but it is
> more obvious where the AVR folder fits in into the llvm source tree.
>
> variant2
> |-- cfe
> |   |-- branches
> |   |-- tags
> |   `-- trunk
> |-- llvm
> |   |-- branches
> |   |-- tags
> |   `-- trunk
> |       |-- lib
> |       |   `-- Target
> |       |       `-- AVR
> |       |-- patches
> |       `-- testcases
> |-- llvm-gcc-4.2
> |   |-- branches
> |   |-- tags
> |   `-- trunk
> `-- website
>    |-- branches
>    |-- tags
>    `-- trunk
>        `-- docs
>
>
> The other idea is about documentation. Like in LLVM we could create a
> website folder and use html files for documentation and maybe put them
> on http://avr-llvm.sourceforge.net.
> I am thinking of docs about:
>
> - Getting Started: how to prepare the llvm source tree and compile llvm
> with avr support
> - Developer Guide: Commit rules, Coding Standards, etc
> - Testing: test cases, test framework, etc
>
> And maybe a front page with links to the ML and the other documents.
>
> I've some early drafts for these documents and will post the for
> discussion if we decide to go this way.
>
> All comments are very welcome.
>
> BR
> Josef
>
>
> ------------------------------------------------------------------------------
> Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
> trial. Simplify your report design, integration and deployment - and focus
> on
> what you do best, core application coding. Discover what's new with
> Crystal Reports now.  http://p.sf.net/sfu/bobj-july
> _______________________________________________
> avr-llvm-devel mailing list
> avr...@li...
> https://lists.sourceforge.net/lists/listinfo/avr-llvm-devel
>

Re: [avr-llvm-devel] current status and future direction oftheavr-llvm project

[Josef E. <za...@za...>]

Weddington, Eric wrote:
>  
> 
>> -----Original Message-----
>> From: Josef Eisl [mailto:za...@za...] 
>> Sent: Sunday, November 29, 2009 8:23 AM
>> To: Weddington, Eric
>> Subject: Re: [avr-llvm-devel] current status and future 
>> direction oftheavr-llvm project
>>
>> Weddington, Eric wrote:
>>>  
>>>
>>>> -----Original Message-----
>>>> From: Josef Eisl [mailto:za...@za...] 
>>>> Sent: Sunday, November 29, 2009 7:56 AM
>>>> To: avr...@li...
>>>> Subject: Re: [avr-llvm-devel] current status and future 
>>>> direction oftheavr-llvm project
>>>>
>>>>
>>>> Yes, as long as we have separate patches for configure.ac and 
>>>> configure
>>>> (or more generally speaking one patch file for user edited autoconf
>>>> files and one for generated output).
>>> Generally I don't like to patch generated files. It's much 
>> better to re-generate the file and then commit that (if 
>> necessary). This is what happens on other projects such as gcc.
>> I understand that but the generation of the configure script requires
>> very special version of autoconf, aclocal and libtool (if you 
>> don't want
>> to edit the AutoRegen.sh script). I think we should provide a 
>> patch for
>> configure for people who don't want to install these versions 
>> of the tools.
> 
> Or an alternative is that we (one of us at least) use those specific versions and regenerate configure and commit that. I worry about patching configure. I don't have a problem with regenerating it.

I've the required versions installed and can commit the updated
configure file. But, to be honest, I don't see why replacing configure
is better than patching it or am I missing something?
Anyway I think this is no big deal. Both ways are ok for me  :) .

Josef

[avr-llvm-devel] [FYI] WebSVN installed

[Josef E. <za...@za...>]

Hello,

I've installed WebSVN on our projects website:
http://avr-llvm.sourceforge.net/websvn/

It is prettier that the ViewVC (in my eyes) and might be useful. As it
is not available as hosted app I've 'installed' it by hand.

Josef

Re: [avr-llvm-devel] current status and future direction oftheavr-llvm project

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

 

> -----Original Message-----
> From: Josef Eisl [mailto:za...@za...] 
> Sent: Sunday, November 29, 2009 8:23 AM
> To: Weddington, Eric
> Subject: Re: [avr-llvm-devel] current status and future 
> direction oftheavr-llvm project
> 
> Weddington, Eric wrote:
> >  
> > 
> >> -----Original Message-----
> >> From: Josef Eisl [mailto:za...@za...] 
> >> Sent: Sunday, November 29, 2009 7:56 AM
> >> To: avr...@li...
> >> Subject: Re: [avr-llvm-devel] current status and future 
> >> direction oftheavr-llvm project
> >>
> >>
> >> Yes, as long as we have separate patches for configure.ac and 
> >> configure
> >> (or more generally speaking one patch file for user edited autoconf
> >> files and one for generated output).
> > 
> > Generally I don't like to patch generated files. It's much 
> better to re-generate the file and then commit that (if 
> necessary). This is what happens on other projects such as gcc.
> I understand that but the generation of the configure script requires
> very special version of autoconf, aclocal and libtool (if you 
> don't want
> to edit the AutoRegen.sh script). I think we should provide a 
> patch for
> configure for people who don't want to install these versions 
> of the tools.

Or an alternative is that we (one of us at least) use those specific versions and regenerate configure and commit that. I worry about patching configure. I don't have a problem with regenerating it.

Re: [avr-llvm-devel] current status and future direction oftheavr-llvm project

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

 

> -----Original Message-----
> From: Josef Eisl [mailto:za...@za...] 
> Sent: Sunday, November 29, 2009 7:56 AM
> To: avr...@li...
> Subject: Re: [avr-llvm-devel] current status and future 
> direction oftheavr-llvm project
> 
> 
> Yes, as long as we have separate patches for configure.ac and 
> configure
> (or more generally speaking one patch file for user edited autoconf
> files and one for generated output).

Generally I don't like to patch generated files. It's much better to re-generate the file and then commit that (if necessary). This is what happens on other projects such as gcc.

[avr-llvm-devel] new directory structure and documentation suggestion [RFC]

[Josef E. <za...@za...>]

Hello,

I would like to suggest another change (hopefully the last one) to our
svn structure.

Sooner or later we will need do customize either the llvm-gcc or the
clang front-end (or both) and I think we should prepare the svn
structure now. The new structure should be similar to the llvm svn
repository to make things easier.

Variant 1: just move the current structure into a new llvm subfolder and
create folders for the front-ends.

variant1
|-- cfe
|   |-- branches
|   |-- tags
|   `-- trunk
|-- llvm
|   |-- branches
|   |-- tags
|   `-- trunk
|       |-- AVR
|       |-- patches
|       `-- testcases
|-- llvm-gcc-4.2
|   |-- branches
|   |-- tags
|   `-- trunk
`-- website
    |-- branches
    |-- tags
    `-- trunk
        `-- docs

The second variant is very similar but the AVR folder is moved to
trunk/lib/Target/AVR. The path is getting a little bit longer but it is
more obvious where the AVR folder fits in into the llvm source tree.

variant2
|-- cfe
|   |-- branches
|   |-- tags
|   `-- trunk
|-- llvm
|   |-- branches
|   |-- tags
|   `-- trunk
|       |-- lib
|       |   `-- Target
|       |       `-- AVR
|       |-- patches
|       `-- testcases
|-- llvm-gcc-4.2
|   |-- branches
|   |-- tags
|   `-- trunk
`-- website
    |-- branches
    |-- tags
    `-- trunk
        `-- docs


The other idea is about documentation. Like in LLVM we could create a
website folder and use html files for documentation and maybe put them
on http://avr-llvm.sourceforge.net.
I am thinking of docs about:

- Getting Started: how to prepare the llvm source tree and compile llvm
with avr support
- Developer Guide: Commit rules, Coding Standards, etc
- Testing: test cases, test framework, etc

And maybe a front page with links to the ML and the other documents.

I've some early drafts for these documents and will post the for
discussion if we decide to go this way.

All comments are very welcome.

BR
Josef

Re: [avr-llvm-devel] current status and future direction oftheavr-llvm project

[Josef E. <za...@za...>]

Weddington, Eric wrote:
>  
> 
>> -----Original Message-----
>> From: John Myers [mailto:ato...@gm...] 
>> Sent: Friday, November 27, 2009 6:39 PM
>> To: avr...@li...
>> Subject: Re: [avr-llvm-devel] current status and future 
>> direction oftheavr-llvm project
>>
>> RE: patch creation guidelines / standards
>>
>> Hello,
>>
>> Do you guys prefer making separate patch files for each 
>> source file or making one patch file based on the type of 
>> 'fix' it was for.
>> For example we have a Triple.h.diff and Triple.cpp.diff but 
>> we could make just one instead like...
>>
>> $    svn diff lib/Support/Triple.cpp 
>> include/llvm/ADT/Triple.h > Triple.dif
> 
> Patch-per-source-file doesn't make any sense. I've always worked on patch-per-logical-change which can span multiple files and directories.

Yes, as long as we have separate patches for configure.ac and configure
(or more generally speaking one patch file for user edited autoconf
files and one for generated output).

Re: [avr-llvm-devel] current status and future direction oftheavr-llvm project

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

 

> -----Original Message-----
> From: John Myers [mailto:ato...@gm...] 
> Sent: Friday, November 27, 2009 6:39 PM
> To: avr...@li...
> Subject: Re: [avr-llvm-devel] current status and future 
> direction oftheavr-llvm project
> 
> RE: patch creation guidelines / standards
> 
> Hello,
> 
> Do you guys prefer making separate patch files for each 
> source file or making one patch file based on the type of 
> 'fix' it was for.
> For example we have a Triple.h.diff and Triple.cpp.diff but 
> we could make just one instead like...
> 
> $    svn diff lib/Support/Triple.cpp 
> include/llvm/ADT/Triple.h > Triple.dif

Patch-per-source-file doesn't make any sense. I've always worked on patch-per-logical-change which can span multiple files and directories.

Re: [avr-llvm-devel] current status and future direction of theavr-llvm project

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

RE: patch creation guidelines / standards

Hello,

Do you guys prefer making separate patch files for each source file or
making one patch file based on the type of 'fix' it was for.
For example we have a Triple.h.diff and Triple.cpp.diff but we could make
just one instead like...

$    svn diff lib/Support/Triple.cpp include/llvm/ADT/Triple.h > Triple.dif

Re: [avr-llvm-devel] release_26 merged back to trunk

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

On Fri, Nov 27, 2009 at 11:01 AM, Josef Eisl <za...@za...> wrote:

> Hello,
>
> Our branches release_2x are a little bit irritating. Should they be
> in sync with trunk (and fail with release 2.x due to api changes etc.)
> or should it be compilable with release 2.x.
> I believe the second option is the one to choose but than it should not
> be merged back to trunk! So its not a branch but a tag.
>
> I think the branch and tag release_2x should always be compilable with the
same upstream LLVM SVN path.
Merging a release branch into trunk probable won't need to happen again. I
believe this was a special case.


My suggestions are moving release_2x to tags. Changes in tags should be
> also applied on trunk (e.g. feature added, etc).
>
> The method I've used with SVN is that the tags directory is a snapshot of a
specific release and no work is done off of tags.
The branches directory is used to work on specific releases and special
versions. The beginning of the version release phase triggers the creation
of a release branch. In this case it would be when branches/release_X.x is
created upstream. I believe this is, at least similar to, how the upstream
project does it ( tags/release_26 wasn't created till after the final
release ).




--John

[avr-llvm-devel] release_26 merged back to trunk

[Josef E. <za...@za...>]

Hello,

I've synced the release_26 branch with trunk and edited it to compile
with the latest trunk version of llvm. The changes are already committed
(revision 40). Please work on trunk from now on.

Our branches release_2x are a little bit irritating. Should they be
in sync with trunk (and fail with release 2.x due to api changes etc.)
or should it be compilable with release 2.x.
I believe the second option is the one to choose but than it should not
be merged back to trunk! So its not a branch but a tag.

My suggestions are moving release_2x to tags. Changes in tags should be
also applied on trunk (e.g. feature added, etc).

BR
Josef

Re: [avr-llvm-devel] Change to AVR.td committed

[Josef E. <za...@za...>]

Weddington, Eric wrote:
> Hi All,
> 
> We should probably set up a 'commits' mailing list and have commit messages go to that.

It seems there is a avr-llvm-commits list up and running. Whoever set it
up, thanks :).

> I just made a change to AVR.td on HEAD. Honestly I haven't tested it yet (I know, I should do that). I reworked the subtarget features and added *all* of the AVR device names, including a bunch of new ones (which I'm adding to AVR GCC right now as well). The subtarget features should also more closely match what is being specified in GCC 4.3.x. Obviously, because some were removed, and some had name changes, this will have to be re-worked in the rest of the code. But I thought this would be a start.

I've checked it against llvm 2.6. Seems to work. I agree, we should  be
consistent with gcc as much as it makes sense. Choosing the same name
for same feature is definitely reasonable. Nice work btw.

Josef

[avr-llvm-devel] Change to AVR.td committed

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

Hi All,

We should probably set up a 'commits' mailing list and have commit messages go to that.

I just made a change to AVR.td on HEAD. Honestly I haven't tested it yet (I know, I should do that). I reworked the subtarget features and added *all* of the AVR device names, including a bunch of new ones (which I'm adding to AVR GCC right now as well). The subtarget features should also more closely match what is being specified in GCC 4.3.x. Obviously, because some were removed, and some had name changes, this will have to be re-worked in the rest of the code. But I thought this would be a start.

Let me know of any complaints/issues.

Eric Weddington

Re: [avr-llvm-devel] current status and future direction of theavr-llvm project

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

 

> -----Original Message-----
> From: John Myers [mailto:ato...@gm...] 
> Sent: Tuesday, November 24, 2009 9:23 PM
> To: avr...@li...
> Subject: Re: [avr-llvm-devel] current status and future 
> direction of theavr-llvm project
> 
> 
> 
> On Tue, Nov 24, 2009 at 2:26 PM, Josef Eisl 
> <za...@za...> wrote:
> 
> 
> 
> 
> 	Compiling against llvm trunk is currently broken but 
> since the 2.6
> 	release is not that old this should be easy to fix.
> 	
> 	The question is if we should work on trunk or on the 
> latest release? I
> 	would prefer working on trunk.
> 	
> 	
> 
> 
> I believe working on the trunk is important otherwise we 
> could fall too far behind the current state of the LLVM src. 
> I think the major issue with working on the trunk is the LLVM 
> developers seem very active making it harder to put time into 
> making the AVR port work rather then keeping up with new 
> features and re-factoring of the src code. I started working 
> on the 2.6 branch since I'm still trying to learn the 
> structure of LLVM but they keep on changing/improving it in the trunk.

That's why I'm hoping that combining our resources and work can help to move this project forward.

So at least we all agree that we should work on the trunk. It does make the most sense.

Re: [avr-llvm-devel] current status and future direction of the avr-llvm project

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

On Tue, Nov 24, 2009 at 2:26 PM, Josef Eisl <za...@za...> wrote:

>
>
> Compiling against llvm trunk is currently broken but since the 2.6
> release is not that old this should be easy to fix.
>
> The question is if we should work on trunk or on the latest release? I
> would prefer working on trunk.
>
>
I believe working on the trunk is important otherwise we could fall too far
behind the current state of the LLVM src. I think the major issue with
working on the trunk is the LLVM developers seem very active making it
harder to put time into making the AVR port work rather then keeping up with
new features and re-factoring of the src code. I started working on the 2.6
branch since I'm still trying to learn the structure of LLVM but they keep
on changing/improving it in the trunk.

Re: [avr-llvm-devel] current status and future direction of theavr-llvm project

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

Hi Josef,

Thanks for the summary, and the build description, both are very helpful.

I understand the desire for working against the trunk, especially if avr-llvm currently doesn't build against the trunk then we should definitely get that fixed. Working against the trunk would allow us to more easily merge upstream when the time comes. Can you describe in a bit more detail how this would work? How do we keep keep synchronized?

I like your idea about setting up test cases as we get features working. Do you have some thoughts on how we do this, or rather where do these test cases fit within the tree? How does this work when we commit upstream? On a similar note, I was looking at the proceedings of the 2009 LLVM Developers Meeting, here <http://llvm.org/devmtg/2009-10/>, and at the presentation "Tutorial: Building backend in 24 hours - A step by step tutorial to build a backend.". Here's a link to the slides: <http://llvm.org/devmtg/2009-10/Korobeynikov_BackendTutorial.pdf>. The author recommends the same step-by-step process with test cases.

I don't have any recommendations on commit guidelines, though I am open to suggestions if anyone has any.

Concerning coding standards, I have two recommendations:
1. Bracket, brace placement. I generally prefer when they are in the same column. For example, change from this:

def MEMri : Operand<i8> {
  let PrintMethod = "printMemOperand";
  let MIOperandInfo = (ops GPRegs, i16imm);
}

To this:

def MEMri : Operand<i8>
{
  let PrintMethod = "printMemOperand";
  let MIOperandInfo = (ops GPRegs, i16imm);
}

For my eyes it just makes it easier to keep track of nesting levels, and to make sure that the blocks are closed properly.

2. Explicit brackets, braces. I know that one can have a single line from an 'if' statement withouts brackets/braces, but I prefer to make them explicit. It may be the case that we have to add or remove lines within the block later and it's easier to already have the brackets/braces in place. I learned this practice years ago when I was writing code for a medical device which required a lot of code review as well as standards approval. For example change from this:

let neverHasSideEffects = 1 in
  def NOP : Pseudo<0x00, (outs), (ins), "nop", []>;

To this:

let neverHasSideEffects = 1 in
{
  def NOP : Pseudo<0x00, (outs), (ins), "nop", []>;
}

Granted, I understand that these formatting suggestions would be for the AVR-specific files only. Anything that touches the generic portions of LLVM should follow the general format of the file that is being modified.

IMHO, I generally prefer to have indentation of 4 spaces rather than 2, but I can be flexible on that point.

I am willing to do the reformatting of the code to conform to the suggestions above.

Other than that I think that the LLVM project has some coding standard guidelines that we should follow.

Lastly, on documentation, I agree with you that we should have good documentation. Though I would like to have some specific suggestions on what needs to be done in this area. I haven't had a chance to look at what exists yet.

Eric Weddington


> -----Original Message-----
> From: Josef Eisl [mailto:za...@za...] 
> Sent: Tuesday, November 24, 2009 3:27 PM
> To: avr...@li...
> Subject: [avr-llvm-devel] current status and future direction 
> of theavr-llvm project
> 
> Hello!
> 
> I want to summarize the current status of the avr-llvm project and the
> next steps from my point of view.
> 
> The current version of llvm is 2.6 and was release on 23.10.09 [1].
> The 2.6 branch of avr-llvm can be built (successfully on linux)
> following the procedure described below:
> 
> - Get the LLVM 2.6 release (e.g. via svn)
> - Get the avr-llvm 2.6 branch
> - setup the build environment
> - configure and build
> 
> On Linux:
> 
> $ svn co http://llvm.org/svn/llvm-project/llvm/tags/RELEASE_26 llvm
> $ svn co
> https://avr-llvm.svn.sourceforge.net/svnroot/avr-llvm/branches
> /release_26
> avr-llvm
> $ cp -rf avr-llvm/AVR llvm/lib/Target/
> $ cd llvm
> $ patch -p0 < ../avr-llvm/patches/configure.ac.diff
> $ patch -p0 < ../avr-llvm/patches/configure.diff
> $ patch -p0 < ../avr-llvm/patches/triple.diff
> $ cd ..
> $ mkdir build
> $ cd build
> $ ../llvm/configure --prefix=$HOME/usr/avr-llvm/ --disable-optimized
> --enable-targets=avr
> $ make
> 
> Compiling against llvm trunk is currently broken but since the 2.6
> release is not that old this should be easy to fix.
> 
> The question is if we should work on trunk or on the latest release? I
> would prefer working on trunk.
> 
> Anyway, the avr-llvm tools like llc don't produce avr 
> assembly code yet.
> 
> In my opinion we should start with simple llvm IR test cases like
> 
> define i8 @main() {
>   ret i8 1
> }
> 
> and add at least one test case for every feature added.
> 
> As soon as the back-end produces correct code we should 
> consider setting
> up a testing framework.
> 
> Another topic for discussion is documentation. In my opinion a good
> project documentation is essential in order to get more people into
> development.
> We should also talk about coding standards, commit guidelines, etc.
> 
> It is easier to do this at the 'beginning' than later.
> 
> Any Suggestions? Thoughts?
> 
> BR
> Josef
> 
> [1] http://llvm.org/releases/2.6/docs/ReleaseNotes.html
> 
> --------------------------------------------------------------
> ----------------
> Let Crystal Reports handle the reporting - Free Crystal 
> Reports 2008 30-Day 
> trial. Simplify your report design, integration and 
> deployment - and focus on 
> what you do best, core application coding. Discover what's new with
> Crystal Reports now.  http://p.sf.net/sfu/bobj-july
> _______________________________________________
> avr-llvm-devel mailing list
> avr...@li...
> https://lists.sourceforge.net/lists/listinfo/avr-llvm-devel
> 

[avr-llvm-devel] current status and future direction of the avr-llvm project

[Josef E. <za...@za...>]

Hello!

I want to summarize the current status of the avr-llvm project and the
next steps from my point of view.

The current version of llvm is 2.6 and was release on 23.10.09 [1].
The 2.6 branch of avr-llvm can be built (successfully on linux)
following the procedure described below:

- Get the LLVM 2.6 release (e.g. via svn)
- Get the avr-llvm 2.6 branch
- setup the build environment
- configure and build

On Linux:

$ svn co http://llvm.org/svn/llvm-project/llvm/tags/RELEASE_26 llvm
$ svn co
https://avr-llvm.svn.sourceforge.net/svnroot/avr-llvm/branches/release_26
avr-llvm
$ cp -rf avr-llvm/AVR llvm/lib/Target/
$ cd llvm
$ patch -p0 < ../avr-llvm/patches/configure.ac.diff
$ patch -p0 < ../avr-llvm/patches/configure.diff
$ patch -p0 < ../avr-llvm/patches/triple.diff
$ cd ..
$ mkdir build
$ cd build
$ ../llvm/configure --prefix=$HOME/usr/avr-llvm/ --disable-optimized
--enable-targets=avr
$ make

Compiling against llvm trunk is currently broken but since the 2.6
release is not that old this should be easy to fix.

The question is if we should work on trunk or on the latest release? I
would prefer working on trunk.

Anyway, the avr-llvm tools like llc don't produce avr assembly code yet.

In my opinion we should start with simple llvm IR test cases like

define i8 @main() {
  ret i8 1
}

and add at least one test case for every feature added.

As soon as the back-end produces correct code we should consider setting
up a testing framework.

Another topic for discussion is documentation. In my opinion a good
project documentation is essential in order to get more people into
development.
We should also talk about coding standards, commit guidelines, etc.

It is easier to do this at the 'beginning' than later.

Any Suggestions? Thoughts?

BR
Josef

[1] http://llvm.org/releases/2.6/docs/ReleaseNotes.html

Re: [avr-llvm-devel] Migrating old repo to the SF repo

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

 

> -----Original Message-----
> From: Josef Eisl [mailto:za...@za...] 
> Sent: Tuesday, November 24, 2009 11:48 AM
> To: Weddington, Eric
> Cc: avr...@li...
> Subject: Re: [avr-llvm-devel] Migrating old repo to the SF repo
> 
> sf.net svn is up and running:
> 
> svn co https://avr-llvm.svn.sourceforge.net/svnroot/avr-llvm avr-llvm
> 
> https://zapster.cc/svn/avr-llvm is now read-only for everyone. If you
> have changed something and not yet committed it to the old repository
> please create a patch against r30 and apply it to the new 
> sf.net repository.

Excellent! I was able to do a successful checkout. :-)

Re: [avr-llvm-devel] Migrating old repo to the SF repo

[Josef E. <za...@za...>]

sf.net svn is up and running:

svn co https://avr-llvm.svn.sourceforge.net/svnroot/avr-llvm avr-llvm

https://zapster.cc/svn/avr-llvm is now read-only for everyone. If you
have changed something and not yet committed it to the old repository
please create a patch against r30 and apply it to the new sf.net repository.

Josef

Weddington, Eric wrote:
>  
> 
>> -----Original Message-----
>> From: Josef Eisl [mailto:za...@za...] 
>> Sent: Tuesday, November 24, 2009 10:48 AM
>> To: Weddington, Eric
>> Cc: avr...@li...
>> Subject: Re: [avr-llvm-devel] Migrating old repo to the SF repo
>>
> 
>>> We should use 'svnadmin dump' and 'svnadmin load', but 
>> those commands don't accept URLs. So it would have to be done 
>> by someone with direct access to the repo files (Josef) and 
>> shell access on SF. This is not necessarily a quick solution 
>> unless Josef is willing to do this.
>>
>> No Problem. I think that is the better solution.
>> If there are no more uncommitted changes around I'll dump the repo an
>> load it on sf.
> 
> Thanks a lot for doing this. That way we can start moving forward.
> 

Re: [avr-llvm-devel] Migrating old repo to the SF repo

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

 

> -----Original Message-----
> From: Josef Eisl [mailto:za...@za...] 
> Sent: Tuesday, November 24, 2009 10:48 AM
> To: Weddington, Eric
> Cc: avr...@li...
> Subject: Re: [avr-llvm-devel] Migrating old repo to the SF repo
> 

> > We should use 'svnadmin dump' and 'svnadmin load', but 
> those commands don't accept URLs. So it would have to be done 
> by someone with direct access to the repo files (Josef) and 
> shell access on SF. This is not necessarily a quick solution 
> unless Josef is willing to do this.
> 
> No Problem. I think that is the better solution.
> If there are no more uncommitted changes around I'll dump the repo an
> load it on sf.

Thanks a lot for doing this. That way we can start moving forward.

Re: [avr-llvm-devel] Migrating old repo to the SF repo

[Josef E. <za...@za...>]

Weddington, Eric wrote:
> Hi John, Josef,
> 
> How do we want to migrate the repo from zapster to the SF repo?
> 
> According to this:
> <http://svnbook.red-bean.com/en/1.5/svn-book.html#svn.reposadmin.maint.migrate>
> We should use 'svnadmin dump' and 'svnadmin load', but those commands don't accept URLs. So it would have to be done by someone with direct access to the repo files (Josef) and shell access on SF. This is not necessarily a quick solution unless Josef is willing to do this.

No Problem. I think that is the better solution.
If there are no more uncommitted changes around I'll dump the repo an
load it on sf.

> 
> According to this:
> <http://svnbook.red-bean.com/en/1.5/svn-book.html#svn.reposadmin.maint.replication>
> We could use svnsync, but again that looks complicated, and I don't know if we could just use the new SF repository after that.
> 
> Regardless of the method, we need to move the repository over somehow. Any suggestions?
> 
> Thanks,
> Eric Weddington
> 
> ------------------------------------------------------------------------------
> Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
> trial. Simplify your report design, integration and deployment - and focus on 
> what you do best, core application coding. Discover what's new with
> Crystal Reports now.  http://p.sf.net/sfu/bobj-july
> _______________________________________________
> avr-llvm-devel mailing list
> avr...@li...
> https://lists.sourceforge.net/lists/listinfo/avr-llvm-devel
> 

[avr-llvm-devel] Migrating old repo to the SF repo

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

Hi John, Josef,

How do we want to migrate the repo from zapster to the SF repo?

According to this:
<http://svnbook.red-bean.com/en/1.5/svn-book.html#svn.reposadmin.maint.migrate>
We should use 'svnadmin dump' and 'svnadmin load', but those commands don't accept URLs. So it would have to be done by someone with direct access to the repo files (Josef) and shell access on SF. This is not necessarily a quick solution unless Josef is willing to do this.

According to this:
<http://svnbook.red-bean.com/en/1.5/svn-book.html#svn.reposadmin.maint.replication>
We could use svnsync, but again that looks complicated, and I don't know if we could just use the new SF repository after that.

Regardless of the method, we need to move the repository over somehow. Any suggestions?

Thanks,
Eric Weddington