constructs that could not be logically mapped from other CPU's into Parrot? Does Parrot assume/use many high level constructs not found in real processors? Some CPU translations, like from CISC to RISC, are clearly easier than the reverse, but other types would prove much more difficult, like those with specialized register windows and DSP vector processors.
I doubt there is much that could not be mapped to Parrot, but Parrot does things that would be impossible
to map directly back to a CPU. Parrot is a mix of low, medium and high level instructions. We have ops
that are jitted to a single instruction or two on a CPU, but we have many more ops that are large routines that would
have to be translated to an API call requiring run-time environment support, continuations, co-routines,
various other odd things which require garbage collectable stacks and execution contexts.
You should be able to easily map your external APIs to Parrot. It has a native interface, so for example if you
have an Oracle app that uses libclntsh.so, you'll simply need to translate any calls to the Parrot Native Interface
by generating the appropriate stub for the Parrot side. For extended processor functions, you'd need to
implement them or JIT them. It may be simpler to support JIT-only for your project. When you talk about
DSP processors, you are out of my range. Register windows ala Sparc could be implemented easily,
and has been discussed periodically, though we chose a different calling convention.
Regarding mapping from Parrot, you'd need to build a libparrot and link to your new environment for
dispatch of those things that don't translate. I'm not sure why you'd want to do this, though. We don't
have any application base to speak of. :)
Understanding what can and can not be translated to and from the virtual Parrot CPU would be the key to my looking at this possibility any deeper, but I could also forsee the possibility of some future type of IDE tools being used to create and debug other applications visually through Parrot as an intermediary between languages and runtime bytecode. Translation of programs (e.g. Perl<=>Python<=>.Net) would also be possible.
There has been some successful work done by various people if you dig back through the archives. I was able to
successfully translate some Java to Parrot, as did someone else; who it was, I forget. Someone else has been
playing with Z-machine lately I think.
Cheers,
-Melvin
