A question about bytecodes

[Tom Rodriguez]

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

You'd need to do loads as well unless you wanted to hack it with  
and'ing to get rid of any sign extension.

tom

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