On 02/18/2015 01:34 PM, Mark Roos wrote:
A statement from Remi defined the reason for my original question very well.

         the ASM packages are only
        re-exported [1] for nashorn

Like the Nashorn folks I am building a language using the jvm for which it  
would
be helpful if there was a standard api for bytecode writing.  One which kept up
with the movement of the jvm and was focused on the needs of language writers. I
am jealous that these folks get toys that I only hear talks on.:

You could try gnu.bytecode, which is a stand-alone part of Kawa:
  http://www.gnu.org/software/kawa/gnu.bytecode/

ASM is very general and powerful, but gnu.bytecode is focused especially on 
generating
very efficient bytecode for a high-level language.  It has various convenience
features that (as far as I know) ASM lacks or is less convenient: Tracking
stack, local variables, types; generating stack map; convenience APIs for
ifs and switches, selecting optimal instructions for arithmetic and constants;
and more. ASM can do all of these things tolerably well, I'm sure, but
it requires a little more manual coding and instruction selection.

OTOH ASM does have more resources and support.  Remi once suggested I should
look into a slimmed-down gnu.bytecode that sits on top of ASM.  However,
I haven't really looked into this; it would especially attractive if/when
ASM is made an official part of OpenJDK.

At a higher level you could use Kawa's other higher-level functionality
for language implementation.   It depends on your goals and the style of
your language.  Kawa is optimized for static compilation and static 
optimization,
and does not use invokedynamic so far.  In spite of this, compilation speed is
pretty good, and start-up time is excellent.  Run-time performance is Java-like.

The downside is that the Kawa higher-level compilation framework is
less modular and nailed-down than gnu-bytecode; it's easiest if you structure
things the way Kawa expects: A Language sub-class, a Compilation sub-class,
a Lexer sub-class (actually the parser), and so on.  See gnu/xquery in
the Kawa source code for an implementation of a very different language
than Kawa's primary language Scheme.
--
        --Per Bothner
p...@bothner.com   http://per.bothner.com/
_______________________________________________
mlvm-dev mailing list
mlvm-dev@openjdk.java.net
http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev

Reply via email to