A question about bytecodes

[Coleen Phillimore]

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_<cpu>.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 <= 256, "too many bytecodes");
> 
> My question is, why is the JVM itself limited to 256 bytecodes? I
> understand the class file is limited due to a bytecode being 1 byte long,
> but I am confused as to why there is a hard limit like this.
> 
> The only place I've seen so far which requires the bytecode to be 1 byte,
> is the C++ interpreter which casts the opcode to a jbyte. Are there any
> other places that require a bytecode to be 1 byte long?
> 
> I was hoping to implement unsigned integers by just adding an 'unsigned'
> opcode, followed by the the opcode to modify (baload, etc) then remap the
> opcode to a 'virtual' unsigned_baload opcode when loading the class into
> the JVM.
> 
> Thanks & Regards
> Stephen
>