parrot's langauges/perl6/* backend for P5
Scott Walters
This is a quasi announcement. As part of a paid project, I just
might have occasion to add a P5 backend to the languages/perl6/*
stuff in the parrot distro. I've been digging through that code,
I'm convinced it is do-able, and I seem to have accidently learned
a good deal about P5's VM while working on typesafety.pm. Whoops.
I mentioned this on the P6I list recently and got some helpful tips.
If anyone here has any suggestions or opinion, fire away. I'd
specificly like to know if
1. Anyone else would like to see this
2. Anyone else has started it or something very similar already
Obviously, this is no long term solution. It would compete with PONIE
in that it would address the question of how to use existing code,
especially CPAN, with the Perl 6 language. It would require less time
to do. It would not solve the problem of maintaing P5's internals
or getting virtual machine support for such things as multiple dispatch,
nor would it create a "common runtime" for open source and free dynamic
languages.
Multiple backends for a language compiler is generally a good thing.
People want to play with Perl 6 the language but less so with the new
virtual machine (virtual machines just aren't that interesting to most
people for some reason).
Wishes and reguards,
-scott
Rafael Garcia-Suarez
> This is a quasi announcement. As part of a paid project, I just
> might have occasion to add a P5 backend to the languages/perl6/*
> stuff in the parrot distro. I've been digging through that code,
> I'm convinced it is do-able, and I seem to have accidently learned
> a good deal about P5's VM while working on typesafety.pm. Whoops.
In a few words, can you give an outline of the implementation idea ?
Scott Walters
tree after context has been propogated and that good stuff and
generates ASCII assembler output for the imcc assembler-like-thing.
I'm proposing a fork to that code, and take the same parse
tree but generate B bytecode, targeting B::Assembler or something
similar - I have no idea what state B::Assembler is in.
Being able to emit text and inspect before assembling it is nice and the
IMCC modules would be burdoned with a lot of binary gunk.
After assembly, the translated module would be spliced into the
bytecode tree of a P5 program care of ByteLoader.
There is no one to one correspondance between Parrot and B so some (most?)
operations will use a B opcode that is too heavy. Many items in the parse
tree map to sequences of Parrot opcodes. These might map to a single B opcode,
a sequence of opcodes, or punt and call a routine written in Perl 5. Other
Parrot ops do something in a single op that would require several B ops or
punting.
-scott
Arthur Bergman
On Monday, December 8, 2003, at 09:43 am, Scott Walters wrote:
>
> languages/perl6/IMCC.pm and languages/perl6/IMCC/* take a parse
> tree after context has been propogated and that good stuff and
> generates ASCII assembler output for the imcc assembler-like-thing.
> I'm proposing a fork to that code, and take the same parse
> tree but generate B bytecode, targeting B::Assembler or something
> similar - I have no idea what state B::Assembler is in.
>
> Being able to emit text and inspect before assembling it is nice and
> the
> IMCC modules would be burdoned with a lot of binary gunk.
>
> After assembly, the translated module would be spliced into the
> bytecode tree of a P5 program care of ByteLoader.
>
> There is no one to one correspondance between Parrot and B so some
> (most?)
> operations will use a B opcode that is too heavy. Many items in the
> parse
> tree map to sequences of Parrot opcodes. These might map to a single B
> opcode,
> a sequence of opcodes, or punt and call a routine written in Perl 5.
> Other
> Parrot ops do something in a single op that would require several B
> ops or
> punting.
>
> -scott
>
And perhaps when Ponie gets better, we can run perl6 on perl5 on parrot
:)
I don't see it as competing with ponie, I see it as the opposite of
ponie.
Arthur