A question about bytecodes

[Tom Rodriguez]

>> 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 can be used with it but they are just a special case encoding of  
ificmp that's not absolutely necessary for unsigned support.

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

Indeed it would.

One thing I might mention is that there's another approach to adding  
unsigned which is to do in the form of an API that's expected to be  
intrinsified by the JVM.  The performance of this would/could be  
exactly the same as a bytecoded version without requiring a change to  
the JVM specification for adoption, which I think is a largely  
insurmountable barrier.  Any way you slice it, javac would have to be  
updated to emit something different so either implementation would  
appear the same from the user standpoint.  The only ugly ones from an  
API perspective are the unsigned byte versions of getstatic/getfield/ 
baload.  Those could simply by fudged by emitting a following & 0xff.   
I vaguely remember a proposal like this being mooted about a few years  
ago but I don't know what happened to it.

If you go the bytecode route with the expectation of JVM spec support  
then I think you would need to update the type signatures to include  
unsigned types.  I think a spec change would require more uniformity  
of implementation.

tom


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