Parrot on RTEMS

Joel Sherrill joel.sherrill at oarcorp.com
Fri Apr 16 14:46:23 UTC 2010


Hi,

I don't want to vote on any projects in your
organization but wanted to speak in generality
about the Parrot on RTEMS proposals and what
they mean to Parrot and RTEMS as projects.
I didn't want to post this as a comment on a
proposal because it is more at a management
level view of the concept than the value of
a particular proposal.

The comments indicated that not being familiar
with the issues you face in embedded systems,
so I wanted to provide a high level view.

RTEMS Background
================
RTEMS is a single process POSIX based embedded
real-time operating system that aims for conformance
with POSIX Profile 51 or 52[1] depending on the user's
configuration.  We have ~85% of the POSIX 1003.1b
API supported.  Currently, we do not have mmap(), shm*(),
asynchronous IO, or fork/exec.  We do not have
virtual memory.

What Parrot Brings to RTEMS
===========================
+ Obviously, the Parrot VM on RTEMS.  This has value
for all the reasons Parrot has value.

+ In general, any time something is ported to RTEMS,
we find something to tweak.  Say a method is missing
or we misread the standard and need to fix the
implementation of a method.  I don't have any
specific expectations of what Parrot will find.

+ Autoconf'ed packages generally build easily to target
RTEMS.  So we don't expect to find any general infrastructure
issues on building Parrot that require RTEMS changes.

What RTEMS Brings to Parrot
===========================
+ Parrot cross building.  This is a known issue.

+ Testing on multiple architectures.  RTEMS runs on
about 12 processor architectures and we have support
for using a FOSS simulator on most of those.  This means
that once Parrot/RTEMS supports one target architecture,
it can be easily tested on others by anyone in your
community.  Cross architecture testing usually shows
assumptions in the code you won't find otherwise.

+ A target where memory matters.  RTEMS is not a virtual
memory environment.  Most target boards have < 1MB RAM.
Some have significantly less.  A common configuration is
running code from Flash memory that is 10x larger than the
amount of RAM available. Others run code from RAM and
there can be anywhere from < 1MB to 1GB RAM.

+ Can't call exit() indiscriminately. Since an RTEMS
application is a single process, calling exit() shuts
down the entire system and reboots or halts the hardware.

+ Assumptions about OS implementation.  POSIX leaves
a fairly wide area for implementations to vary and be
compliant. I don't know if Parrot accidentally depends
on one of these but if it does, it will turn up.

+ Code coverage analysis ([2], [3]).  We do code coverage analysis
at the instruction and branch taken/not taken level using
FOSS CPU simulators.  We currently can do this on about 5-6
architectures.  This infrastructure could be used to ensure
your Parrot test suites cover the entire implementation at
a very fine level of detail.

Conclusion
==========
I think there is more work to do on the Parrot side to
properly support cross builds to any embedded RTOS than
there is on the RTEMS side to support running Parrot.
Chris Johns hacked together a port last year which showed
a couple of tests running and highlighted the challenges.

The decision on what to slot is yours but I
wanted to attempt to let you know what I think
this project offers to both organizations.

References
==========
[1] http://www.embedded.com/2001/0104/0104feat4table2.htm
[2] http://www.rtems.com/wiki/index.php/RTEMS_Coverage_Analysis
[3] http://www.rtems.org/ftp/pub/rtems/people/joel/coverage/

-- 
Joel Sherrill, Ph.D.             Director of Research&  Development
joel.sherrill at OARcorp.com        On-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
    Support Available             (256) 722-9985




More information about the parrot-dev mailing list