M0 is one of those goals. This small set of opcodes represents the minimum
necessary platform-specific code required to implement the rest of Parrot. M0
is a specification. Like Perl 6 is a specification, there can be multiple
implementations. The demo implementation is a Perl program, and my C
implementation is the second implementation (and hopefully a likely candidate
to become part of Parrot itself).

Like Perl 6, M0 is a specification and a test suite.

Unlike Perl 6, the M0 test suite is tied to the original implementation.
That is to say, when you run the M0 tests, you exercise the Perl demo M0
implementation.

A small task for the interested is to decouple the M0 test suite from the
Perl M0 implementation and make those tests available for multiple
implementations. This probably means representing those tests in a form with
expected inputs and outputs, perhaps running M0 source code through an
assembler to create M0 bytecode, and running the tests against an arbitrary
implementation.

Perl 6's test suite has an interesting capability whereby the list of tests
contains metadata on which known implementation should skip or try to run but
not expect to pass arbitrary test files. The #perl6 channel on irc.freenode.net
can give you more details about this fudging process.

This project does easily parallelize across multiple interested people.
Coordinating in #parrot on irc.perl.org will help.

As a bonus test, the C implementation should allow optional testing with Valgrind, if installed. All tests should run
without memory leaks or invalid memory accesses. (I tested the C implementation
by hand, but automating this is essential for further development.) This task
is slightly more complex, but should be within reach for any Perl programmer of
modest experience.