On 2019-03-07 11:10, Brian Burkhalter wrote:
On Mar 7, 2019, at 10:04 AM, Andrew Haley <a...@redhat.com
<mailto:a...@redhat.com>> wrote:
On 3/6/19 7:31 PM,raffaello.giulie...@gmail.com
<mailto:raffaello.giulie...@gmail.com>wrote:
the latest version of the patch, replacing the one found at [1].
In the next days, my sponsor Brian Burkhalter will publish it as a
webrev.
I still believe you'd be better off defining an unsigned multiplyHigh than
all that messing about with shifts and masks in rop().
There is in fact an open issue for unsigned multiplyHigh:
https://bugs.openjdk.java.net/browse/JDK-8188044
Brian
Hi Andrew,
a couple of weeks ago I tried to refactor the code assuming the
existence of unsignedMultiplyHigh() (either as some future intrinsic or
as a Java method) and a wider representations of g with either 127 or
128 bits:
g = g1 2^64 + g0
with either
2^63 <= g1 < 2^64 (128 bits)
or
2^62 <= g1 < 2^63 (127 bits)
Unfortunately, the resulting code of rop() isn't any simpler. That's
because then an intermediate sum can overflow the 64 bits of a long. As
a consequence, there's need for more elaborate logic to determine
the carry and other slightly more complicated computations to assemble
the final result. All in all, the resulting code has more operations and
looks longer.
I tried with four variants. In addition to the mults, which are needed
anyway, the current code has 3 shifts, 3 adds, 2 bitwise logicals. As
mentioned, I couldn't come up with a solution that would help reducing
this count.
I would be glad to hear of better solutions and to write down a
mathematical proof for the document.
In the meantime I got rid of the last division. There's no division at
all in the whole algorithm.
Greetings
Raffaello
