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:
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:
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":
4. There are not enough unused opcodes which could be used for unsigned
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
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
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
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.
mobile : [masked]
email : [address removed]
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...