John~ I am confused... The fact that I don't use Janino's parser doesn't theoretically stop me from bootstrapping the compiler. In fact, Janino's parser is only useful if the language I am compiling is actually Java. If my language goes
Foo -> Foo AST -> Janino AST -> bytecode I can still get a bootstrapped system in the usual way (implement a Foo compiler in Java, use that to implement a Foo compiler in Foo, throw away the Java one and compile using earlier versions of the compiler). Matt On Thu, Dec 17, 2009 at 3:33 PM, John Cowan <[email protected]> wrote: > On Thu, Dec 17, 2009 at 2:54 PM, Matt Fowles <[email protected]> > wrote: > > John~ > > That depends on how you squint. I never bother with Janino's parser; I > walk > > my AST and generater a Janino AST and then cook that directly. I added > the > > method > > > > SimpleCompiler.cook(Java.CompilationUnit compilationUnit) > > > > to the API expressly for this purpose. > > Ah. I can't run my compiler on the JVM until it's capable of > compiling itself, so I need to generate Java code. > > > > > > > Matt > > > > On Thu, Dec 17, 2009 at 2:49 PM, John Cowan <[email protected]> > wrote: > >> > >> On Thu, Dec 17, 2009 at 1:24 PM, Charles Oliver Nutter > >> <[email protected]> wrote: > >> > On Thu, Dec 17, 2009 at 12:17 PM, John Cowan <[email protected]> > >> > wrote: > >> >> I proposed a long time ago to add "goto" to Janino, which would > remove > >> >> a huge amount of the incentive to generate bytecode directly. The > >> >> proposal was turned down, but the new moderator might be more > >> >> receptive, especially if a patch was provided. (You can do a lot of > >> >> what goto does with "do ... while (false)" and judicious use of > break, > >> >> but it's messy.) > >> > > >> > Ideally I should never have to worry about goto; I should be able to > >> > feed something a Java/JVM-aware CFG and know it will produce the best > >> > possible code for me. > >> > >> I don't understand this. Janino's input is Java 1.4 source code, not > >> a CFG; it's an embeddable compiler. > >> > >> > > >> >> I'm not sure that making Janino do its own optimizations is really a > >> >> win: too-clever bytecode generators, as we know, can cause JITs to > >> >> pessimize the code. But I'm willing to be convinced otherwise. > >> > > >> > I think this is true for small cases, but certainly not for large > >> > ones. For example, sometimes it's just damned useful to be able to say > >> > "inline this code everywhere...no really, just do it". Or in JRuby's > >> > case, to be able to say "treat finals as really finals, finally!" and > >> > not compile multiple accesses as multiple accesses. There's lots of > >> > reasons why doing some up-front optimization can help, since even the > >> > best JVM jits don't do *everything* for us. > >> > > >> > In JRuby's compiler, we're going to do a lot of this on a Ruby level > >> > before feeding it to whatever bytecode generation, but ideally our > >> > bytecode-generating backend would just translate our Ruby CFG into a > >> > rough Java-like CFG and the backend will do additional optimization > >> > passes to produce the best-possible bytecode. > >> > > >> > Another optimization a good compiler backend could do for us would be > >> > generating smaller synthetic methods if basic blocks of code appeared > >> > frequently in a very large body. Right now, javac and friends are > >> > pretty dumb...you feed it a big chunk of code, it puts it into a big > >> > method. But if it were smart about splitting up blocks into synthetic > >> > submethods, we'd have mo' betta inlining possibilities, smaller units > >> > of code, and generally better performance. > >> > > >> > There's a lot of opportunity here. > >> > > >> > - Charlie > >> > > >> > -- > >> > > >> > You received this message because you are subscribed to the Google > >> > Groups "JVM Languages" group. > >> > To post to this group, send email to [email protected]. > >> > To unsubscribe from this group, send email to > >> > [email protected]<jvm-languages%[email protected]> > . > >> > For more options, visit this group at > >> > http://groups.google.com/group/jvm-languages?hl=en. > >> > > >> > > >> > > >> > >> > >> > >> -- > >> GMail doesn't have rotating .sigs, but you can see mine at > >> http://www.ccil.org/~cowan/signatures > >> > >> -- > >> > >> You received this message because you are subscribed to the Google > Groups > >> "JVM Languages" group. > >> To post to this group, send email to [email protected]. > >> To unsubscribe from this group, send email to > >> [email protected]<jvm-languages%[email protected]> > . > >> For more options, visit this group at > >> http://groups.google.com/group/jvm-languages?hl=en. > >> > >> > > > > -- > > > > You received this message because you are subscribed to the Google Groups > > "JVM Languages" group. > > To post to this group, send email to [email protected]. > > To unsubscribe from this group, send email to > > [email protected]<jvm-languages%[email protected]> > . > > For more options, visit this group at > > http://groups.google.com/group/jvm-languages?hl=en. > > > > > > -- > GMail doesn't have rotating .sigs, but you can see mine at > http://www.ccil.org/~cowan/signatures > > -- > > You received this message because you are subscribed to the Google Groups > "JVM Languages" group. > To post to this group, send email to [email protected]. > To unsubscribe from this group, send email to > [email protected]<jvm-languages%[email protected]> > . > For more options, visit this group at > http://groups.google.com/group/jvm-languages?hl=en. > > > -- You received this message because you are subscribed to the Google Groups "JVM Languages" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/jvm-languages?hl=en.
