A question about bytecodes

[Stephen Dawkins]

(resent to list as I forgot to reply to all)

Hi

Thank you for your reply, it is very informative.

Yes, I am looking to have signed and unsigned versions of the opcodes at
the same time, so a global switch is not an option.

I am looking to have the 'unsigned' opcode work similarly to the 'wide'
opcode in the class file, I just don't really want to add another lookup
like wide has in the template interpreter. I believe it would be better to
slightly abstract the JVM from the class file definition. The JVM doesn't
really care how the bytecodes are represented in the class file, whether
it takes 1 or 2 bytes.

I want to have 2 seperate opcodes in the class file (like wide does), but
transform them into a 'virtual' opcode (like the _fast_getfield and
friends) while loading it.

I only raise this as even though unsigned integers can be implemented
without going over the 256 code limit, I also want to try my hand at
adding SSE primitives to Java, and that will certainly push it over.

Thanks & Regards
Stephen
>
> 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
>>
>
>