addressalign-toparrow-leftarrow-rightbackbellblockcalendarcameraccwcheckchevron-downchevron-leftchevron-rightchevron-small-downchevron-small-leftchevron-small-rightchevron-small-upchevron-upcircle-with-checkcircle-with-crosscircle-with-pluscrossdots-three-verticaleditemptyheartexporteye-with-lineeyefacebookfolderfullheartglobegmailgooglegroupshelp-with-circleimageimagesinstagramlinklocation-pinm-swarmSearchmailmessagesminusmoremuplabelShape 3 + Rectangle 1ShapeoutlookpersonJoin Group on CardStartprice-ribbonShapeShapeShapeShapeImported LayersImported LayersImported Layersshieldstartickettrashtriangle-downtriangle-uptwitteruserwarningyahoo

JVM support for unsigned arithmetic

From: user 8.
Sent on: Sunday, August 19, 2012 12:55 PM
Hello fellow LJC members,

I'd like to share an idea with you guys *who firmly understand and 
firmly believe* that unsigned arithmetic is definitely useful and 
necessary for some specific applications and algorithms.


----- Please! please! please! -----
if you either don't know what unsigned arithmetic operations are about 
or if you don't believe that unsigned arithmetic operations are 
necessary, please open a separate discussion. This thread is intended to 
the problem of how unsigned operations could be supported, not to 
explain what the problem is and/or why unsigned operations are necessary.
----- Please! please! please! -----



OK. Introduction and recommendations done, we can now start.

Well... I've faced the same trouble again: the JVM does not provide 
support for unsigned arithmetic.
This is reported here: 
http://bugs.sun.c...­

I found that unsigned arithmetic is going to be partially supported in 
JDK8, via some static methods. I also found one library which implements 
unsigned arithmetic types ubyte, ushort, uint and ulong on top of 
BigInteger and BigDecimal. I'm discarding these solutions (from this 
discussion!) because they either do not solve properly the problem or 
because performance of unsigned operations would be unacceptable when 
compared with signed operations.

Going ahead, I found some reasonable explanations about why JVM 
designers decided to exclude unsigned arithmetic operations. Among these 
explanations, one is absolutely relevant: it would increase the need of 
opcodes for unsigned operations, which would basically double the 
initial effort invested on early implementations of the JVM. Let's 
examine the idea:

I found the reference of opcodes below, organized by numbers:

     http://homepages....­

We can observe some interesting characteristics:

1. All opcodes take only a single byte, making the JVM simpler and smaller.
2. There is support only for signed arithmetic operations.
3. The "unused" opcodes[masked] are not actually "unused": 
http://homepages....­
4. There are not enough unused opcodes which could be used for unsigned 
arithmetic operations.

The only actually unused opcode I found after a quick inspection is:
      0xBA (186)   http://homepages....­

This basically points out to two solutions:

1. Redefine opcodes accepted by the JVM, eventually extending opcodes to 
two bytes.
2. Employ the opcode 0xBA with the meaning of "unsigned".

Well... idea (1) can be easily discarded for obvious reasons. Let me 
simply skip more explanations.
Let's then discuss idea (2) and let's assume that opcode 0xBA is now 
named "unsigned", for the sake of generalization.



The idea of around opcode "unsigned" is shown below:

1. Opcode "unsigned" would mean: "prepare for an unsigned arithmetic 
operation". This opcode would be necessarily followed by an opcode 
relative to a signed arithmetic operation.

2. Internally, the JVM would keep all existing code base relative to  
signed arithmetic operations as it is, untouched, for full backwards 
compatibility.

3. When the interpreter finds opcode "unsigned" , it would require one 
more opcode to be read and would dispatch execution to a completely new 
implementation in the code base, intended to support unsigned arithmetic 
operations.

4. When native code is generated, opcode "unsigned" would mean that 
unsigned arithmetic operations of the native host processor must be 
necessarily employed, instead of signed arithmetic ones.

I'm sure this idea unwinds to lots of considerations and issues.
Your thoughts are welcome.

Thanks

-- 
Richard Gomes
mobile : [masked]
email  : [address removed]
twitter: frgomes
YM     : rgomes1997
gtalk  : rgomes1997
--------------------­--------------------­--------------------­-------
Skype: dial skype2ippi           then dial[masked] when prompted.
GTalk: dial [address removed]  then dial[masked] when prompted.
SIP  : dial [address removed]
iNUM : [masked]http://www.inum.n...­

Our Sponsors

  • Our Blog

    Read the latest news from the LJC

  • RecWorks Ltd

    Fixing Tech Recruitment using the Power of Community

  • jClarity

    Java/JVM Performance Analysis Tools & mentoring for Java related matters

  • LJC Aggrity

    Our LJC Aggrity site contains blog posts from our members

  • LJC Book Club

    Our Book club with book reviews from our members

  • Devoxx UK

    Java Community Conference in collaboration with the LJC, 8-10th June 16

  • SkillsMatter

    "Host, help organise, promote, film many of our meetings."

  • IBM

    Build Enterprise-grade apps at start-up speed.

  • New Relic

    New Relic makes sense of billions of metrics a day in real time.

  • Hazelcast

    Hazelcast is the leader in operating in-memory computing.

  • Java.Net

    We are an official Java User Group recognised by Oracle's JUG program

  • JRebel

    Free 3 month J-Rebel license.

  • O'Reilly

    40% discount on printed books and 50% on e-books.

  • Craft Rebellion

    Your choice of fresh craft beer, delivered. For 10% off use ‘LJC'

People in this
Meetup are also in:

Sign up

Meetup members, Log in

By clicking "Sign up" or "Sign up using Facebook", you confirm that you accept our Terms of Service & Privacy Policy