A question about bytecodes

[Stephen Dawkins]

Hi

Due to the way the the original assert is worded, there is still a limit
of 256 entries in the Bytecode::Code enum, so even using another opcode as
a prefix things are going to get messy (I'm thinking of the table in
templateTable.cpp).

'unsigned' is fine, as it reuses the original set of opcodes and just
modifies their meaning, however for anything new, like say SIMD primitives
the 2nd opcode will have no relation to the opcodes that currently use
0-202.

Prehaps I'm just being naive, but as I don't know much of hotspot (I only
got it building a few days ago), how much effort would it be to resize
opcodes to 16-bit (or 32-bit, but 65,536 opcodes should be enough for
anyone...) through out the VM? (The class file definition wouldn't have to
change.)

Thanks & Regards
Stephen

>         The template (assembly language) interpreter bytecode dispatch
> code assumes
>  one-byte opcodes.
>
>  If you're willing to accept more overhead, you can overload use of the
> 'wide'
>  opcode.  For all practical purposes, it acts like an x86 opcode prefix
> byte and
>  thus adds 256 bytecode operations.  Unfortunately, it's already used for
> some
>  of the instructions you want to change, including iinc.  In that case,
> you can
>  take one of the currently unused opcodes, name it something like
> 'twobyte'
>  and implement it the same way 'wide' is currently implemented.
>
>  See the method TemplateTable::wide() at the bottom of, e.g.,
> templateTable_sparc.cpp.
>  It effectively does a redispatch using an alternate dispatch vector.
>
>  The corresponding code in bytecodeInterpreter.cpp (see 'CASE(_wide)')
> does the same
>  thing.
>
>  Paul
>
>  Coleen Phillimore wrote:    The limit of one byte per bytecode opcode is
> inherited from the classfile format.  When we load classfiles, in
> classFileParser.cpp we do:    if (code_length > 0) {
> memcpy(m->code_base(), code_start, code_length);   }  Also, if you are
> using the template based interpreter, there are several assumptions that
> the bytecodes are one byte each, see interp_masm_.cpp dispatch_epilog().
> The size of the bytecode is also implied by the structure in
> cpCacheOop.hpp which is the constant pool cache.  This is used by both
> interpreters.  Are you rewriting the bytecodes after they are loaded from
> the class in the rewriter?  So there are only certain instances of baload
> for instance that are unsigned and others are sign extended?  If you want
> all unsigned, just add a switch in globals.hpp.  Hope this is helpful.
> Coleen  On Tue, 2009-01-06 at 05:00 -0800, Stephen Dawkins wrote:
>   Hi  I've been hacking around on the JVM, attempting to add support for
> unsigned integers. I've managed to add several opcodes (based on baload,
> bipush, iinc, i2l, saload and sipush) that do zero-extending, rather than
> sign-extending.  However, I came across a limit in the JVM. In
> bytecodes.cpp, there is this line:  assert(number_of_codes