A question about bytecodes

[Tom Rodriguez]

You don't really need to do saload since caload is an unsigned 16 bit  
load.  Don't you need to an unsigned version of lcmp?  The if??  
bytecodes operates on the 3 way result from that so you don't _have_  
to add unsigned variants of them I think.  They just duplicate the  
functionality of the if_icmp?? bytecodes with a 0.  So since you  
aren't adding unsigned getfield you must be adding a new type  
descriptor to the VM signatures to deal with unsigned fields?

tom

On Jan 8, 2009, at 6:02 AM, Stephen Dawkins wrote:

>>>> 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
>>
>
> baload, saload, i2l, i2b, idiv, ldiv, irem, lrem, i2f, i2d, l2f, l2d
> if_icmplt, if_icmpge, if_icmpgt, if_icmple, iflt, ifge, ifgt, ifle
>
> I believe that's the complete list.
>
> bipush, sipush and iinc are possible candidates, but can be achieved  
> via
> other methods.
>
> Regards
> Stephen
>