A question about bytecodes

[Joseph D. Darcy]

Stephen Dawkins wrote:
> (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.
>   

One of the benefits of using a two's-complement encoding for integral 
types is that signed and unsigned add, subtract, and multiply give the 
same bit-wise results.  Therefore presumably only conversion, divide, 
and comparison operations would be needed to explicitly operate on 
unsigned data.

-Joe

> 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
>>>
>>>       
>>     
>
>
>
>