(Sorry, this got off the list by accident.) On Mon, 24 Jan 2011 10:38 -0500, "Andrew Whitworth" <[email protected]> wrote: > > Embarassing silence ensues, because I didn't keep a record of where > > exactly I found or didn't find the information > > No problem. I am getting the sense that we need to focus attention on > the quality of documentation in general, not just any one particular > faulty document. > > You are correct that the documentation for HLL::Compiler and > PCT::<everything> is lacking. I'll make sure to focus there first. > > > Well, I had this crazy idea a few weeks ago... The Fortran 2008 standard > > was released in October 2010. No current compiler actually implements > > the full Fortran 2003 standard yet (the first partial implementation > > appeared six years after the fact), and the trend seems to be to pick > > the most popular new features from 2003 and 2008 and implement those > > first. If that continues, the first full Fortran 2008 compiler may not > > appear until, say, 2015. > > A working Fortran 2008 compiler on top of Parrot would be amazing, and > is definitely the kind of project I would be interested in seeing come > to life. I can't offer more than modest help myself since I have so > many other projects in the air at once, but I will definitely be > willing and able to help out when needed. > > > - The Fortran 2008 standard is an extremely well written document. Even > > though it's not certain the full standard is implementable (since nobody > > has done it yet), it is straightforward to make at least a rudimentary > > compiler. > > Do you happen to have a link I could look at?
The final, official ISO/IEC standard document costs money. ISO/IEC 1539-1:2010 (aka Fortran 2008): http://www.iso.org/iso/iso_catalogue/catalogue_tc/catalogue_detail.htm?csnumber=50459 The final draft document that the ISO committee voted on is available at: ftp://ftp.nag.co.uk/sc22wg5/N1751-N1800/N1791.pdf The biggest possible changes between the draft and the official standard are typo fixes, so the draft should be reliable. There are two related standards, 1539-2:2000 and 1539-3:1999, which introduce variable length strings and conditional compilation to Fortran 95, respectively. The former (I think) is obsolete in Fortran 2008, which already supports variable length strings, and the latter can be ignored for now. There may also be a few Technical Reports (extensions to the standard) in future, which will refine the C interoperability interface and coarray semantics. (As an aside, it should be fairly easy to implement C interoperability using Parrot's NCI.) > > - Parallelism would be very limited, but that's fine. The standard > > leaves room for singlethreaded implementations of coarrays, for > > instance. > > Threading is one area that the Parrot team is going to be focusing on > very heavily in a few months. If Fortran needs improved threading, > make those desires known and we will make sure to take your needs into > account. If I do have the time and resources to start the implementation, I would first focus on getting the syntax parsed and keep things single-threaded, so parallelism would only come after everything else. In fact, I would lift as much as I can from Parrot, ignoring all performance-related issues. For instance, one would likely have to use Integer PMCs for Fortran integers rather than native integers, since they have a few peculiarities. For reference, the Fortran 2008 coarray mechanism is conceptually quite simple. Parallel "threads" are called "images", and they communicate via shared arrays. There are some built-in functions to synchronise execution and ensure only one image is executing a piece of code at a time. The standard leaves the actual implementation open on purpose, so it would be possible to just implement it with Posix threads at first. > > - Interfacing with existing native-code Fortran libraries may not be > > possible (although it might be via Parrot's dynamic library loading > > mechanism...). > > > > ... > > > > Besides, having a Fortran implementation on Parrot raises interesting > > possibilities, such as rapid prototyping, which is currently impossible > > with Fortran compilers. Or creating an embeddable Fortran interpreter. > > The 2008 standard is a strict superset of the previous standards, so in > > theory this would enable one to compile, say, LAPACK into PIR, which > > could then be used from other supported languages. (LAPACK is written in > > Fortran 77.) > > You may be interested to see Parrot-Linear-Algebra (PLA), a wrapper > for the BLAS (and, eventually, LAPACK) libraries for Parrot. This is a > project I personally started a while back. It links to both C and > Fortran versions (CBLAS, ATLAS, BLAS, etc) and provides fast matrix > math. I have BLAS bindings working already to great success. I am > still designing the LAPACK interfaces. > > https://github.com/Whiteknight/parrot-linear-algebra > > The test suite for PLA is currently broken because a library I was > relying on to run the unit tests has been unmaintained. I'll be fixing > that issue soon and cutting a release of it that will work with 3.X > Parrot. Interesting! They may be of use in implementing the intrinsic mathematics functions in Fortran; I would hate to have to write my own Bessel functions (introduced as intrinsic in Fortran 2008). (Talk about abstractions on top of abstractions: Fortran implemented on top of a virtual machine by using native Fortran libraries through the VM. On the other hand, you wouldn't have to hand-tune the mathematics functions yourself, since the native Fortran compiler will have produced very efficient code for you.) Another reason I mentioned LAPACK is that it comes with an extensive compiler test suite and can be used to verify the compiler works. It's also a large, non-trivial source code base, good for stress-testing a compiler. > > - There's no straightforward mapping between Fortran modules and > > submodules and Parrot modules (I haven't found any documentation for the > > module mechanism in PIR other than classes). You would have to write > > some kind of a linker in PIR. > > We have some linker-like tools already (pbc_merge, etc). We can write > more depending on what you need. > > This project sounds like an extremely interesting one, and I hope > Parrot has the things you are looking for to support it. So far it seems at least possible. Let's not get carried away, though. I have quite a bit on my plate as well, and it will very likely take me a few months to do the background work and become familiar with Parrot. I'll compile my findings and plans into a document in case I need to throw the ball to someone else. Regards, Ville Koskinen _______________________________________________ http://lists.parrot.org/mailman/listinfo/parrot-dev
