[antlr-interest] build issues: bytecode assembly generation

Terence Parr parrt at cs.usfca.edu
Thu Oct 21 10:30:23 PDT 2004



On Oct 21, 2004, at 10:11 AM, Matt Benson wrote:

>
> --- Terence Parr <parrt at cs.usfca.edu> wrote:
>> Anybody wanna comment on the build issues or
>> coolness factor of inline
>> assembly (for programs that generate programs
>> anyway)?
>
> As a longtime lurker my two cents has an exchange rate
> of half or less, but I think inlining would be very
> cool, and more versatile as you hinted.  I have done
> some quick searching however and couldn't find any
> documentation about inline bytecode in Java
> sourcefiles.  I'd appreciate any background on that...
> or am I misunderstanding you?

Yeah, i've never seen it before.  I'm actually amazed at how many 
bytecode / classfile programs there are but no "inline assembly code" 
tools.  Further, all tools puke at the slightest hint of trouble in a 
..class file (accept for the antlr classfile.g written by Andreas, 
naturally).

My goal is basically to avoid .class file generation / reading totally 
by making the compiler do it.  All I would have to do is open up the 
..class file and replace a blank method (there's a comment as the method 
containing the bytecodes)

private static int predictDFA1(IntegerStream input) {
/*!bytecode
aload 0
iconst 1
.....
*/
}

with the real code after I assemble it. The only trick here is that you 
have to read the ENTIRE .class file and PARSE it to figure out where 
that method is.  UNLESS, you're sneaky and have your translator read 
the .java file and replace !bytecode comments with a special sequence 
of java statements that leaves a unique bytecode pattern (heck "int 
aspecialname=magic" might do it).  Compile the translated .java file.  
Then, you just do a binary replace of the small sequence with the big 
one and, voila, you have inserted assembly code!

Cool, eh?  I love that concept because it's devious.  The ultimate way 
to write bytecode assembly, right!

Anyway, this way, I don't have to generate a separate .class file for 
DFAs...they can be in the same .java file as the parser itself.

The only reason I don't jump on this is that javac is sooooo slow and 
it would make antlr seem slow as a result.

Anybody have experience running jikes from within Runtime.exec or 
running the tools.jar version of javac within a VM?

I want antlr to run out of the box without any dependencies except 
perhaps javac.

Ter
--
CS Professor & Grad Director, University of San Francisco
Creator, ANTLR Parser Generator, http://www.antlr.org
Cofounder, http://www.jguru.com
Cofounder, http://www.knowspam.net enjoy email again!





 
Yahoo! Groups Links

<*> To visit your group on the web, go to:
    http://groups.yahoo.com/group/antlr-interest/

<*> To unsubscribe from this group, send an email to:
    antlr-interest-unsubscribe at yahoogroups.com

<*> Your use of Yahoo! Groups is subject to:
    http://docs.yahoo.com/info/terms/
 





More information about the antlr-interest mailing list