addressalign-toparrow-leftarrow-rightbackbellblockcalendarcameraccwcheckchevron-downchevron-leftchevron-rightchevron-small-downchevron-small-leftchevron-small-rightchevron-small-upchevron-upcircle-with-checkcircle-with-crosscircle-with-pluscontroller-playcredit-cardcrossdots-three-verticaleditemptyheartexporteye-with-lineeyefacebookfolderfullheartglobe--smallglobegmailgooglegroupshelp-with-circleimageimagesinstagramFill 1launch-new-window--smalllight-bulblinklocation-pinm-swarmSearchmailmessagesminusmoremuplabelShape 3 + Rectangle 1ShapeoutlookpersonJoin Group on CardStartprice-ribbonprintShapeShapeShapeShapeImported LayersImported LayersImported Layersshieldstartickettrashtriangle-downtriangle-uptwitteruserwarningyahoo

Re: [ljc] JVM support for unsigned arithmetic

From: user 8.
Sent on: Monday, August 20, 2012 11:47 PM
Hello,

Thanks Ben for your explanation.

Besides Ben's explanation about large array support in JDK 9, I found this which leads me to think that JDK 9 ( or maybe JDK 10 ? ) would have to have support for unsigned variables, in order to better interoperate with native languages.

On the other hand, this (by Joe Darcy @ Oracle) leads me to think that (finally!) bug [masked] was admitted to be existent and relevant but, unfortunately what is being pushed onto JDK 8 relative to unsigned arithmetic is far from what is being expected by developers who posted on bug [masked] and many other complaints around the Internet. In a nutshell, the code which was pushed moves the responsibility to circumvent the problem from developers' code to the JDK, which is something that hurts more than helps, because the root cause of the problem is not being addressed, but overlooked by the foundation library of the entire ecosystem (namely; the JDK).

If JDK 9 aims to provide large arrays and JDK 10 aims to integrate with GPUs and FPGAs properly, a true solution involving true unsigned values, true unsigned variables and true unsigned integer arithmetic operations is needed.

Once Sun (or Oracle?) closed bug [masked] (which was opened in 2001!), I was considering resurrecting the subject, but rewritting it in a such way which could eventually be fruitful/successful, instead of being just another bug report doomed to die, like the previous one.

Ben's explanation about WIDE and the imaginary new UNSIGNED opcode makes me think that both approaches would be equally difficult to implement and would lead to a long list of improvements and issues. Given the non-economical cost/benefit relation involving unsigned arithmetic, the current user audience for such matter, etc, etc...  chances are that it will never be implemented, unless a certain critical mass is able to demonstrate that it will cost less to do it properly in the first attempt than trying to amend the platform and miss the boat of a serious HPC platform, when support for GPUs and FPGA could leverage the JVM to a serious candidate to be considered for numerical computation.

The way changes are being pushed onto JDK8 at the moment, makes me think I'd better consider Scala running on top of CLR (Microsoft? oh! no!) or compiling Scala straight onto native code with LLVM. Another alternative would be the still incipient IBM X10, which compiles to Java and also C++. Maybe these alternatives need less time to mature properly than JDK needs to mature not-properly?

I'm concerned with the way numeric computation is being overlooked in the platform. Handling of overflows is another concern I have: the solution being pushed onto JDK8 does not look appropriate to me, because detection of overflow is not responsibility of the library (namely: JDK), but the processor (namely: JVM). Well... this is another subject, but reinforces my concerns about how numeric computation was never addressed properly by the platform and, unfortunately, is still being overlooked.

Thoughts? Let's keep the ball rolling :)

btw: I'm copying Joe Darcy, hoping he tells me I'm absolutely wrong.

Thanks all,

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.net/what-is-inum/voice-reach
On 20/08/12 15:39, Ben Evans wrote:
Hi,

This mechanism is quite similar to that used by the wide opcode.

For people who aren't familiar, there are two forms of the load and
store opcodes. The regular form is

ILOAD u1

ie the load operation is followed by a single byte, which indicates
which local variable (from 0 to 255) is to be stored on the operand
stack.

For the extremely rare case that more than 256 local variables are
needed, then instead the bytecode will be:

WIDE ILOAD u2

It is important to note that in the second form, ILOAD is not
considered to be a valid opcode, and in particular is not a valid
branch target.

So, the two options for unsigned arithmetic would be to use a new
UNSIGNED opcode or to attempt to reuse WIDE.

There are issues with both approaches. A totally new bytecode would
require a lot of copy & pasted code (e.g. changes to the verifier to
ensure that the embedded opcode of UNSIGNED is not ever used as a
target). Attempting to reuse WIDE may have other issues - in
particular I remain unconvinced that an unsigned load will never be
required - and also don't forget that large arrays are a great hope
for SE 9 - and accessing large array offsets may require similar
trickery.

Thanks,

Ben

On Mon, Aug 20, 2012 at 1:45 PM, Richard Gomes <[address removed]> wrote:
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.com/bugdatabase/view_bug.do?bug_id=4504839

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.inf.ed.ac.uk/kwxm/JVM/codeByNo.html

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.inf.ed.ac.uk/kwxm/JVM/note.html
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.inf.ed.ac.uk/kwxm/JVM/unused.html

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.net/what-is-inum/voice-reach





--
Please Note: If you hit "REPLY", your message will be sent to everyone on this mailing list ([address removed])
http://www.meetup.com/Londonjavacommunity/
This message was sent by Richard Gomes ([address removed]) from LJC - London Java Community.
To learn more about Richard Gomes, visit his/her member profile: http://www.meetup.com/Londonjavacommunity/members/8057610/
Set my mailing list to email me

As they are sent
http://www.meetup.com/Londonjavacommunity/list_prefs/?pref=1

In one daily email
http://www.meetup.com/Londonjavacommunity/list_prefs/?pref=2

Don't send me mailing list messages
http://www.meetup.com/Londonjavacommunity/list_prefs/?pref=0
Meetup, PO Box 4668 #37895 New York, New York[masked] | [address removed]



--
Please Note: If you hit "REPLY", your message will be sent to everyone on this mailing list ([address removed])
http://www.meetup.com/Londonjavacommunity/
This message was sent by Ben Evans ([address removed]) from LJC - London Java Community.
To learn more about Ben Evans, visit his/her member profile: http://www.meetup.com/Londonjavacommunity/members/10704992/
Set my mailing list to email me

As they are sent
http://www.meetup.com/Londonjavacommunity/list_prefs/?pref=1

In one daily email
http://www.meetup.com/Londonjavacommunity/list_prefs/?pref=2

Don't send me mailing list messages
http://www.meetup.com/Londonjavacommunity/list_prefs/?pref=0
Meetup, PO Box 4668 #37895 New York, New York[masked] | [address removed]



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