Stability of PCT, PGE, NQP, PIR for HLL development

Ville Koskinen parrot at vrkosk.iki.fi
Mon Jan 24 16:17:07 UTC 2011


(Sorry, this got off the list by accident.)

On Mon, 24 Jan 2011 10:38 -0500, "Andrew Whitworth"
<wknight8111 at gmail.com> 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


More information about the parrot-dev mailing list