What, exactly, is gained by compiling to Java and then compiling the Java to bytecode? Are there optimizing compilers out there for Java source code => byte code that you can leverage? If not, then is there a particular example of a place where it's easier to generate Java code than byte code? I just don't see what you're gaining, although I'm intrigued.
~~ Robert. [email protected] wrote: > > Some jvm languages have problems left to solve: > > ---------------------------------------------Problem1--------------------------------------------- > P1) Whole program type inference to allow use of jvm primitives for > their numeric types and math. > (Even the use of Strings and other types we tend to be > a HolderForATypicalJREClass) > > Some strategies used: (So far the compilers that get closest to > optimal have done the hard ones like S5 and S1,) > > S1) Some people had to "force themselves" to use java primitives. And > when they could not get away with it, at least used > some JRE version of a java.lang.PrimitiveHolder. Stayed frustrated > for a few hours but finally conceded that this was no longer their > problem. > > S2) Some (like myself) used my.lang.PrimitiveHolder. Consoling myself > with "java did it!" or "when its time, *eventually* will fix this to > use primitives" or "what knucklehead thought 16 bits is enough to > represent any character?" or "they forgot unsigned byte.. I need a > special holder that helps mark this as so" > > S3) Create a couple generic HolderForJavaObject and optimize the use > of reflection > or make HolderForWidelyUsedJREInterface(s) > > S4) Guess what the user will likely use based on the types from MyLang: > MyLangJavaNetSocket, MyLangJavaReader, MyLangJavaWriter, etc > > S5) Or enforce strong typing and never cheat using a > HolderForATypicalJREClass... force my compiler to invoke-virtual > > S6) and/or make my MyLangWhatever implement JRE interfaces.. Later on > work on passing JRE objects thru > > S7) Pick out a set of well documented interfaces from something > external like CORBA > .. and make my compiler only target that > > * Know I've missed a few (We could try on this list to keep > enumerating them) > > > ---------------------------------------------Problem2--------------------------------------------- > P2) Excluding P1, if some user would have just written > their application in .java in many cases, > The bytecode that would have resulted from their code would > be a tad better than ours. > > S8) invoke static > to MyLangLibrary.tooWierdOfFeatureToCompileSmartly(MyLangASTLikeObject > obj) {... written in java ..} > > S9) Make the user just write java in a new featurefull syntax > > S10) inline S8 into bytecode (Not a strategy: But allot of people > think it is.. profiling might tell otherwise.. ("method too large to > JIT")) > > S11) have 2nd-4th passes that optimize their intermediate proposals > before bytecode representation is emitted. > > S12) Some may even run bytecode optimizations like SOOT > One JVM lang even had to write their own post process: GJIT > (http://code.google.com/p/gjit/), > > > * Know I've missed a few (We could try on this list to keep > enumerating them) > > > ---------------------------------------------Problem3--------------------------------------------- > P3) Maintaining and improving our compilers to solve P1 & P2 better. > > > S13) Improve the built in functions of our runtime > > S14) Use JAVAP/JAD/JODE on the emitted output. (I think we of are > constantly doing this.. but...) > > !!!!Now the reason for my Email!!!! > > S15) Create a .Java emitter branch > > Instead of emitting bytecode .. make compilers emit java code that > would have produced the same bytecode > (jvm language permitting/omitting optimizations = Can some on list > please enumerate what they cannot translate to .java?) > > > - Compile an entire user program into a tree of .java files > - Decide if that was how you would have written their > program in .java > If not, see how many simplistic changes you could make > that could be done at compiler/translator level > - Get an overview of how many changes you'd like to make > (like S1 thru S9) at the compiler but would be just be too > grueling > - Could you write an AST transform/refactor tool > targeting this .java source to improve it? > If so, can this be incorporated into the compiler as a > pass? > - Now that their program is a .java program.. Include your > Runtime and make a java project out of it. > since you are a java hacker, you can experiment and > profile what are good and bad ideas better. to find what optimizations > are worth it > With that information .. re-include it into the > emitter/compiler. > > Pretty much IMO most complier writers that try to do all the above in > typical S14 and profiling and have even reached best-cases quite often .. > Most jvm languages go directly from source to bytecode: > We want to get to execution quickly as possible or Can advertise as > a real compiler. or Makes the user feel more secure with their > proprietary code > > But regardless feel they never reached "Whole program" efficiency I > think it is because the limited scope of S14 > I suspect the more time one spends in the java-emitter branch of their > jvm language (dealing with entire user programs), > the better their compiler trunk will become. > > Here is an example of a complier-as-emitter.. An entire user's program > was translated from SubLisp to .java > > line 117 of > http://larkc.svn.sourceforge.net/viewvc/larkc/trunk/platform/src/com/cyc/cycjava/cycl/constant_reader.java?revision=254&view=markup > > <http://larkc.svn.sourceforge.net/viewvc/larkc/trunk/platform/src/com/cyc/cycjava/cycl/constant_reader.java?revision=254&view=markup> > > It uses a for/next look on a boxed Fixnum. but if that was fixed.. > line 118 which only consumes Fixnums has to be updated as well. > And so the cycle begins, replacing fixnums with primitive 'long's (or > maybe 'int's if array index accesses will be found in the call tree). > This code could be manipulated with some heavy java AST manipulation > tools. Same way bytecode could have been.. > > I just bring all this up in case people are looking for new ideas and > might find sometimes easier to work with java in their compiler > improvement workflows. > > Myself, once I got the .java down that I thought best its just as easy > to compile and then get the best bytecode version for a compiler. > > > > > > -- > > 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=. -- 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=.
