Using unsigned library work in the JDK (original) (raw)
Ulf Zibis Ulf.Zibis at gmx.de
Thu Jan 26 17:13:55 UTC 2012
- Previous message: Using unsigned library work in the JDK
- Next message: Using unsigned library work in the JDK
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Am 26.01.2012 17:11, schrieb Roger Riggs:
Is there any performance impact of the method call vs the &0xff? Hotspot will in-line the code but for VMs with less sophisticated optimizations it will be a net loss. +1 At least in interpreter and maybe -client compiler the new code would have performance impact.
Its unfortunate that between the method name and need to qualify with the class (or use static imports) that the code is longer and not always clearer. +1
- static import could become ambiguous using Byte.toUnsignedInt() + Short.toUnsignedInt() at same time.
- The shortest I can think: Short.unsigned(byte) Integer.unsigned(short) Long.unsigned(int) BigInteger.unsigned(long)
- Nothing would be ambiguous, using static import.
The existing idiom for unsigned byte is easy enough to recognize. For the places where multiple bytes are assembled into short or integer, a new method with a specific purpose would be a clearer modification to the code. +1
- Would be an ideal candidate for intrinsification
- See similar (vice versa): http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6914113
- For type short a cast is needed using current implementation: short s = (short) Byte.toUnsignedInt(byte)
Seeing the use in the IO context, the method names may be more useful if they reflect the data taken from the argument. For example, asUnsignedByte(buffer[i]) . +++ 1
But I/O is more about assembling bytes and less about unsigned arithmetic. Maybe java.io.Bits would be the right home for things like that.
-Ulf
- Previous message: Using unsigned library work in the JDK
- Next message: Using unsigned library work in the JDK
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]