[EMAIL PROTECTED] (Scott Walters) writes: > I have work-related reason to add a "B" backend for Perl 5 to the > perl6 compiler. I'm looking at creating an assembler for Perl 5's > "B" bytecode along the lines of IMCC, and creating patches against > languages/perl6/IMCC.pm and languages/perl6/IMCC/* to conditionally, > using some sort of phrasebook, generate assembly for either Parrot > or B.
This would involve some nontrivial refactoring, since both are unashamedly machine-dependent, and freely emit blocks of assembly directly from the AST walk. Unless B assembly is a lot like parrot assembly, simply replacing (or factoring out) these chunks might not be the best way. Of course, I've never used B assembly, so discount this impression appropriately. Everything up to IMCC* (i.e. parsing, tree munging, and "context" (wannabe typing)) should be fine, though. > The B assembler would use B::Generate to build up a bytecode tree, > and then B::Deparse to dump P5 or else more likely dump the raw > bytecode and use ByteLoader to suck it back in. Far be it from me to discourage you, but IMHO languages/perl6 is less complete and correct than the rest of Parrot. However, while the grammar reflects an older incarnation of Perl 6, it's written in fairly clean Parse::RecDescent, and it is ahead of the code generation in terms of completeness. You might be better off both performance-wise and other-wise either: 1. just using Parrot to run the subset of perl6 you need; or 2. using the languages/perl6 parser to translate directly to Perl 5. Since the languages are similar in a lot of ways, this should not be too hard in most cases (and very painful in a few), and since languages/perl6 doesn't do any optimization, you're not losing anything. > This should have been posted to perl6-language, but I'm not > subscribed there. This is probably internals, since it doesn't concern language design. Let me know if you have any other questions. /s
