Hi, 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. Kind Regards James On 13 April 2013 03:20, Hal Finkel <hfinkel at anl.gov> wrote:> ----- Original Message ----- > > From: "Anton Korobeynikov" <anton at korobeynikov.info> > > To: "Matthieu Brucher" <matthieu.brucher at gmail.com> > > Cc: "Bill Wendling" <isanbard at gmail.com>, "LLVM Developers Mailing > List" <llvmdev at cs.uiuc.edu> > > Sent: Friday, April 12, 2013 9:04:22 AM > > Subject: Re: [LLVMdev] GSoC project questions. > > > > > Indeed, dragonegg supports Fortran, but through a gfortran bridge. > > > The > > > really interesting part in Fortran is in fact arrays! > > > > > > Anyway, it's just my opinion, I'm a simple user ;) > > Fortran has its own standard library and it's damn big. Also, the > > Fortran grammar is not the simplest (or, rather - straightforward > > one). So this certainly looks too big for GSoC. > > > > Though, it might be a good start for someone. > > > > I believe Bill (CCed) started something few years ago. So, maybe he > > can share his thoughts on this project. > > FWIW, I also started working on a Fortran frontend (derived from Clang, > but mostly just to piggyback on the Driver and CPP infrastructure). > https://github.com/hfinkel/lfort > > If you're interested in contributing, that would be great. Nevertheless, I > think that Anton is right. Creating a quality Fortran compiler is a > community effort, and seems too big for a GSoC project. Perhaps we could > identify some separately-useful component. > > -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 > > > _______________________________________________ > 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/73b7c051/attachment.html>
> 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? -- With best regards, Anton Korobeynikov Faculty of Mathematics and Mechanics, Saint Petersburg State University
----- 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 >