----- Original Message -----> From: "Anton Korobeynikov" <anton at korobeynikov.info> > To: "James Courtier-Dutton" <james.dutton at gmail.com> > Cc: "Hal Finkel" <hfinkel at anl.gov>, "Bill Wendling" <isanbard at gmail.com>, "LLVM Developers Mailing List" > <llvmdev at cs.uiuc.edu> > Sent: Saturday, April 13, 2013 9:12:39 AM > Subject: Re: [LLVMdev] GSoC project questions. > > > I agree that creating a complete Fortran compiler is a huge effort. > > But what about approaching it from a test driven development > > perspective? > > We start with a few small Fortran programs as "test cases". > > The GSoC task then gives the task as getting test case 1 to work. > > We could also apply this of "lfort". Determine a test case that > > currently > > fails on lfort, and ask the GSoC task to pass the test. > All this make sense only if there is interested party in long-term > development and maintenance. Otherwise the code will bitrot really > quickly and thus will be waste of time and money. Is there such a > party?I am certainly interested in long-term development and maintenance. I think that the first step toward making a useful Fortran compiler is this: 1. It should be able to compile BLAS: http://www.netlib.org/blas/ (these are Fortran 77, and have no I/O, so should be relatively simple) 2. If that is complete, then move on to LAPACK: http://www.netlib.org/lapack/index.html (these use some subset of Fortran 90) As you can see from the test cases currently in lfort, most of the driver functionality and lexical analysis (for both Fortran 77 and 90) is done, and I've started on parsing (and semantic analysis and codegen for) variable declarations and some simple statements. I think that a motivated student could make a lot of headway, and should be able to at least finish step 1. Thoughts? -Hal> > -- > With best regards, Anton Korobeynikov > Faculty of Mathematics and Mechanics, Saint Petersburg State > University >
Thanks for your replies. Working on the lfort compiler would certainly be an interesting project for me for this GSoC. I have studied lfort repository and commits, and I see that it has a lot of stuff for C/C++, am I correct that this is a fork of Clang? If this is correct, I wonder why this approach was chosen instead of starting out from scratch - is it because Clang already has a lot of code which can be reused for the Fortran compiler? I'm also unfamiliar with Clang and I was a bit overwhelmed when I saw the lfort repository at first because of this. If I were to work on this project, would I be required to use the Clang code? 2013/4/13 Hal Finkel <hfinkel at anl.gov>> ----- Original Message ----- > > From: "Anton Korobeynikov" <anton at korobeynikov.info> > > To: "James Courtier-Dutton" <james.dutton at gmail.com> > > Cc: "Hal Finkel" <hfinkel at anl.gov>, "Bill Wendling" <isanbard at gmail.com>, > "LLVM Developers Mailing List" > > <llvmdev at cs.uiuc.edu> > > Sent: Saturday, April 13, 2013 9:12:39 AM > > Subject: Re: [LLVMdev] GSoC project questions. > > > > > I agree that creating a complete Fortran compiler is a huge effort. > > > But what about approaching it from a test driven development > > > perspective? > > > We start with a few small Fortran programs as "test cases". > > > The GSoC task then gives the task as getting test case 1 to work. > > > We could also apply this of "lfort". Determine a test case that > > > currently > > > fails on lfort, and ask the GSoC task to pass the test. > > All this make sense only if there is interested party in long-term > > development and maintenance. Otherwise the code will bitrot really > > quickly and thus will be waste of time and money. Is there such a > > party? > > I am certainly interested in long-term development and maintenance. I > think that the first step toward making a useful Fortran compiler is this: > > 1. It should be able to compile BLAS: http://www.netlib.org/blas/ (these > are Fortran 77, and have no I/O, so should be relatively simple) > > 2. If that is complete, then move on to LAPACK: > http://www.netlib.org/lapack/index.html (these use some subset of Fortran > 90) > > As you can see from the test cases currently in lfort, most of the driver > functionality and lexical analysis (for both Fortran 77 and 90) is done, > and I've started on parsing (and semantic analysis and codegen for) > variable declarations and some simple statements. I think that a motivated > student could make a lot of headway, and should be able to at least finish > step 1. Thoughts? > > -Hal > > > > > -- > > With best regards, Anton Korobeynikov > > Faculty of Mathematics and Mechanics, Saint Petersburg State > > University > > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20130413/1fad607d/attachment.html>
----- Original Message -----> From: "Alex L" <arphaman at gmail.com> > To: "Hal Finkel" <hfinkel at anl.gov> > Cc: "Anton Korobeynikov" <anton at korobeynikov.info>, "Bill Wendling" <isanbard at gmail.com>, "LLVM Developers Mailing > List" <llvmdev at cs.uiuc.edu> > Sent: Saturday, April 13, 2013 11:34:43 AM > Subject: Re: [LLVMdev] GSoC project questions. > > > Thanks for your replies. > Working on the lfort compiler would certainly be an interesting > project for me for this GSoC.Great!> I have studied lfort repository and > commits, and I see that it has a lot of stuff for C/C++, am I > correct that this is a fork of Clang? If this is correct, I wonder > why this approach was chosen instead of starting out from scratch - > is it because Clang already has a lot of code which can be reused > for the Fortran compiler?Yes, lfort started out as a fork of Clang, but I don't think that is overly relevant at this point. There are a few things from Clang that the Fortran compiler could really reuse: 1. The driver/tools infrastructure (the code that finds the system libraries, knows how to call the assembler, linker, etc.) 2. The C preprocessor (in practice, a lot of Fortran code assumes the existence of an integrated C preprocessor). 2a. The lexical analysis framework, and to some extent, the classes for printing nice error messages 3. The directory layout and regression-testing setup At this point, I've pretty much finished taking advantage of all of those pieces in lfort, and the remainder of the core code from Clang needs to be replaced with Fortran-specific bits. Keeping the same general design probably makes sense, but I could certainly be convinced otherwise.> I'm also unfamiliar with Clang and I was a > bit overwhelmed when I saw the lfort repository at first because of > this. If I were to work on this project, would I be required to use > the Clang code?No. I think that you might want to use Clang for inspiration on design, but you'd certainly not be bound to that. If you'd like to take a much more start-from-scratch approach, you can also look at the code that Bill put together: https://github.com/isanbard/flang - If you use that as a base, we can always merge it with the useful lfort pieces later. Thanks again, Hal> > > > 2013/4/13 Hal Finkel < hfinkel at anl.gov > > > > > ----- Original Message ----- > > From: "Anton Korobeynikov" < anton at korobeynikov.info > > > > To: "James Courtier-Dutton" < james.dutton at gmail.com > > > Cc: "Hal Finkel" < hfinkel at anl.gov >, "Bill Wendling" < > > isanbard at gmail.com >, "LLVM Developers Mailing List" > > < llvmdev at cs.uiuc.edu > > > > Sent: Saturday, April 13, 2013 9:12:39 AM > > Subject: Re: [LLVMdev] GSoC project questions. > > > > > > I agree that creating a complete Fortran compiler is a huge > > > effort. > > > But what about approaching it from a test driven development > > > perspective? > > > We start with a few small Fortran programs as "test cases". > > > The GSoC task then gives the task as getting test case 1 to work. > > > We could also apply this of "lfort". Determine a test case that > > > currently > > > fails on lfort, and ask the GSoC task to pass the test. > > All this make sense only if there is interested party in long-term > > development and maintenance. Otherwise the code will bitrot really > > quickly and thus will be waste of time and money. Is there such a > > party? > > I am certainly interested in long-term development and maintenance. I > think that the first step toward making a useful Fortran compiler is > this: > > 1. It should be able to compile BLAS: http://www.netlib.org/blas/ > (these are Fortran 77, and have no I/O, so should be relatively > simple) > > 2. If that is complete, then move on to LAPACK: > http://www.netlib.org/lapack/index.html (these use some subset of > Fortran 90) > > As you can see from the test cases currently in lfort, most of the > driver functionality and lexical analysis (for both Fortran 77 and > 90) is done, and I've started on parsing (and semantic analysis and > codegen for) variable declarations and some simple statements. I > think that a motivated student could make a lot of headway, and > should be able to at least finish step 1. Thoughts? > > -Hal > > > > > > > -- > > With best regards, Anton Korobeynikov > > Faculty of Mathematics and Mechanics, Saint Petersburg State > > University > > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > >