A question about bytecodes

[Stephen Dawkins]

Tom Rodriguez wrote:
> You don't really need to do saload since caload is an unsigned 16 bit 
> load.
Thats correct.

>  Don't you need to an unsigned version of lcmp?  

*sigh*, it seems like everytime I think I've got all of them, another
one appears.

> The if?? 
> bytecodes operates on the 3 way result from that so you don't _have_ to 
> add unsigned variants of them I think.

I assume the if?? variants can operate on a regular int aswell? Then
we'll need an unsigned ifge and ifgt. iflt and ifle are actually invalid
for unsigned numbers.

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

Ok, it looks like I'll need unsigned versions of them too, and the
_fast_* versions.

I really don't want to go through the VM adding 3 new primitives in just
for unsigned integers. From what I've seen this would be an excessive
amount of work. (I should point out, I really don't know what I'm doing
yet :))

The one issue I've got is, as I don't want to go add new type signatures
  how do I decern return types/parameter types? I thought about an
annotation @Unsigned.

Regards
Stephen

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