Parrot on RTEMS: Parrot Configuration is Clean

This week for the Google Summer of Code, I finished work on getting Parrot to configure cleanly. The latest commit can configure Parrot without any errors. The long and the short of it is that the configure steps and hints file is completed although several of the hints are currently hard-coded in. Next week I will focus on getting the build to complete without errors. A quick refresher:

Parrot does not come with a Makefile but comes with a Perl script called that runs a number configuration of steps. One steps determines what CPU and architecture we are running, one checks for the sizes of native types like ‘int’ and ‘float’ and ‘double’. Some steps wrangle templates to generate Makefiles and source code while others compile programs to check how a system compiler actually handles certain pieces of code. Essentially these steps capture all the information necessary to configure Parrot to compile correctly on whatever system we are running.

The problem is that with RTEMS our development system will not necessary be the same architecture as the target platform. For example, I’m running Fedora Core 12 on x86 but my code and compilers target sparc. So these automated tests won’t run. We need some secret sauce to get Parrot to compile on different hardware architectures for RTEMS.

The first part of the secret sauce was overriding the default compiler, linker, and other parts of the tool chain. This was simple because can accept the overrides not only through the command line, but we can also specify an external file to hold our entire configuration recipe. This helps keep things organized, makes it easier to generate, and avoids the problem of a max command line argument length.

The second step was to disable as many of the auto configuration steps as possible. Again, this was simple because the external file can also specify which steps we want to skip. Last week I disabled every step which generated a lot of errors from the configuration script. Reading these errors showed me exactly what information was necessary and from there I could either provide the information in a hints file (in lieu of running the step) or I could re-enable the step (if it didn’t run hardware dependent code).

This week I finished the hints file and removed the last remaining configuration bugs. That means Parrot can now run the script with RTEMS variables and will generate a Makefile and not throw any errors. It’s not time to celebrate quite yet – many of the values are hard-coded into the hints file rather than probed from the RTEMS. And the build still hangs on a few wrong values in the hints file.

To alleviate the first problem would require a re-write of the secret sauce with either autoconf or with perl. Autoconf would be nice because RTEMS already uses it and there are probably many examples of how to get exactly the information I want. Perl would be nice because I already know the language unlike autoconf / m4.

A rewrite is definitely in the future, but for now I will work on getting the build clean and a ‘Hello World’ example in PIR running before that. Once I’ve worked out all of the problems there I will begin to work on getting the Parrot test suite running, rewriting the secret sauce, testing multiple hardware configurations, and then even playing with High Level Languages (HLLs) that run on top of Parrot like Rakudo (Perl 6 on Parrot) or Cardinal (Ruby on Parrot). Finally, I’d like to round things out with a series of tutorials (or even screencasts) showing how to install RTEMS, Parrot, and some HLLs on a blank target environment.

Posted in Google Summer of Code | Comments Off on Parrot on RTEMS: Parrot Configuration is Clean

Comments are closed.