[EMAIL PROTECTED] wrote:
> On Oct 2, 2:23 am, Per Bothner <[EMAIL PROTECTED]> wrote:
>
>> Don't forget gnu.bytecode, which I wrote for Kawa (starting in
>> 1996):http://www.gnu.org/software/kawa/api/gnu/bytecode/package-summary.html
>> It uses arrays extensively, which makes it very efficient,
>> It also has many useful features for compiler writers.
>
> Per, I think I already bugged you about this while ago, but can you
> please remind what features from gnu.bytecode you are referring to?
Some of these are no-brainers, and ASM probably has them too.
But here are some convenience features that I find useful:
* Help in selecting the right load instruction: For example emitPushInt
takes an arbitrary int, and selects between iconst_m1 .. iconst_5,
bipush, sipush, or ldc/ldc_w with automatic constant pool entry
creation.
* Similarly, emitPushString(String) handles Strings longer than 2^16
chars by automatically splitting it into smaller segments and
concatenating them.
* Help in constant pool management - does not create duplicate
constant pool entries.
* Automatically generates code to initialize a primitive array from
a compile-time constant array.
* Emits line numbers and LocalVariableTable attributes.
* Emits JSR-45 "SourceDebugExtension" attribute.
* Semi-automatic local variable management.
* Handles try-catch-finally *expressions*, which can push a result
(in both try and catch clauses) onto JVM stack. Also saves and
restores any values already on the JVM stack.
* Support for simple self-tail-calls (jump to "beginning" of
function, which could be an inlined function).
* Help for emitting/managing switch statements, automatically
selecting the "best" instruction.
* Fixups and fragments: You can emit code into a bytecode fragment",
and then re-arrange the fragments. This is useful for avoiding needless
jumps. (This probably doesn't matter for Hotspot, but it reduces code
size and might help for simpler VMs.) Re-ordering fragments is
non-trivial, because the size of (say) a switch instruction depends on
alignment. Kawa also automatically generates "long jumps" - when the
jump offset becomes more than will fit into a signed 16-bit offset,
Kawa will generate long 32-bit jumps, with trampolines as needed.
(This is not really tested, and it has limited usefulness given that
method-bodies are in practice limited to 2^16-1 bytes, but at least
Kawa will allow jumps that are larger than 2^15, which effectively
doubles the maximum method size.)
--
--Per Bothner
[EMAIL PROTECTED] http://per.bothner.com/
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
