bkuhn wrote:
> >I *think* that the consensus is that we should make it easy for people who
> >want to port to the JVM, or the so-called ".NET Implementation Language".
> >As the JVM porter, I'd like my life easy, but I don't expect perl6 to hand
> >me a JVM implementation---I just want to right components and interfaces so
> >it is not as hard as a job as it is for perl5.
>
Dan Sugalski wrote:
> While the JVM and .NET.Thingie shouldn't be *the* dead-on target for output
> bytecode, their limitations should be kept in mind to some extent.
I'm all for it, and will happily lend what I know about the JVM to the
discussion.
I didn't want to presume that we'd want to limit ourselves by JVM and other
VM architectures. Of course, consideration should be given, but there's a
fine line between examining implications of design decisions and allowing
the design of system A to fundamentally change the design of system B. ;)
That being said, I'm all for using JVM bytecode as the native bytecode for
Perl. But, I am far too biased to be taken seriously. ;)
> If, for example, the bytecode *required* the use of pointers (no, don't
> ask me how, this is a contrived example... :)
Ok, I won't ask, but I am nevertheless confused by what you mean about the
"bytecode requiring pointers". Perhaps it is very contrived. ;)
> Having a solid and correct reference doc for the output bytecode is
> probably the single most helpful thing we can do for folks writing things
> that munch the bytecode.
Actually, I don't think that munching Perl bytecode into Java bytecode is
the best approach. I tried going from B:: (which is effectively an IR,
albeit a problematic one) to Java bytecode directly, and that was full of
problems, because it required doing too much by hand. I have had to scrap
that approach.
After hacking at this for a year or two, I believe that the best approach of
doing Perl->JVM is to go from some Perl IR to a "Java IR". For Perl5, I am
currently using Kawa as the Java IR and what B:: provides (for lack of
something better) as the Perl IR.
This is why I want such a clearly defined API for the IR and for any
internal data structures used by the IR---I'd like to write a backend that
morphs the Perl IR into the "Java IR" to generate JVM bytecode.
Dan, does that fit with your thinking?
--
Bradley M. Kuhn - http://www.ebb.org/bkuhn
PGP signature
