Parrot was implemented in C, and to my recollection implemented various iterations of bytecode syntaxes, notably PBC (parrot byte code).
Rakudo Perl 6 developers took the route of developing Perl 6 through an intermediary language NQP, which is a language aimed at making it easy to implement interpreted languages.
Rakudo (the implementation of Perl 6 that run on MoarVM) is implemented in NQP, and started out on Parrot through an implemention of NQP for Parrot.
NQP[1] stands for Not Quite Perl, and shares various features with Perl, but is much more constrained in features as capabilities, making it easier to implement in a VM.
Because it's mostly implemented in NQP, it's fairly easy to port to a new VM, as all you have to do is get NQP running on that VM, and Perl 6 is mostly ported. For example, this is how the Java port happened within a few months of announcement. NQP was implemented, and then 95% of Perl 6 was already working.
When a new VM instead of Parrot was desired, MoarVM was conceived of as a VM to natively run NQP (rather than NQP on top of the native VM bytecode). Porting Rakudo to it was relatively easy, since Rakudo targets NQP, not a specific VM.
Pugs, conversely, was an interpreter/VM for Perl back in the days of Parrot, and ran its own Perl 6 implementation directly (no intermediary language, and it wasn't Rakudo). It was writtem in Haskell.
Niecza was another direct implementation of Perl 6, but implemented in C# for .Net. I don't believe it used NQP.
PBC was the bytecode format, the human readable low-level syntax was called PASM and the slightly higher-level synax was called PIR.
Besides PIR, other languages still close to the metal were NQP versions (though I don't remember the exact relationship between NQP/NQP-rx/parrot-nqp) and eventually Winxed.
> Besides PIR, other languages still close to the metal were NQP versions (though I don't remember the exact relationship between NQP/NQP-rx/parrot-nqp) and eventually Winxed.
I vaguely remember NQP/NQP-rx etc as being branches with reimplementations or new features, but I could be way off. I remember Winxed, but I'm not sure I realized Whiteknight implemented it at the same layer as NQP instead of on top of it. That would explain why some other new language implementations started using it instead of NQP, which I recall (e.g. I think someone started up a new Ruby on Parrot implementation after Winxed that used Winxed). I miss reading Whiteknight's blog posts on massive changes he was working on.
The way I remember it, the issue was that later versions of NQP moved towards greater backend independence and no longer mapped directly to Parrot VM semantics (eg 6model), so Parrot had to rely on older NQP version, making Winxed an attractive alternative.
The first relevant version of compiler tools were called PGE/TGE, written in PIR and based on the notion of attribute grammars and grammar engines. The first versions of NQP grew out of those.
I believe early versions of NQP were hosted in the Parrot repo, but they started to be developed out of tree and eventually were completely hosted out of the tree.
NQP was an improvement over PGE/TGE in many ways, so some of Parrot's internal tools were created in or ported to NQP.
Eventually (I believe with NQP-rx), NQP forked into an incompatible version out of tree. As you mention, when the next incompatible revision of NQP was being planned, it was no longer an attractive target for Parrot, because it was:
* developed out of tree
* developed out of Parrot's release cycle
* backwards incompatible
* "backend independent"
I still maintain that it made little sense for Parrot to depend on an external project, evolving rapidly, offering little stability, with the express intent to obviate Parrot.
That's interesting. I'm not sure why I remembered it so strongly as Whiteknight's invention, but it probably has to do with how much he talked about it, and that my initial exposure to it was through his blog.
> The way I remember it, the issue was that later versions of NQP moved towards greater backend independence and no longer mapped directly to Parrot VM semantics (eg 6model), so Parrot had to rely on older NQP version, making Winxed an attractive alternaive.
That sounds likely. The whole situation was a clusterfuck. To my knowledge, some people are still really upset about it and how it played out (but at this point I don't really see how it could have gone any other way).