Comments on Sun's Proposal for Extension of Java Floating Point in JDK 1.2

[David Chase]

In responses to PEJFPS, do keep in mind that Java
source-language local variables are not necessarily
evident at the VM level, so rules defined in terms
of Java source rules (e.g., "narrow to double on
assignment") may not be expressible at the bytecode
level.

Also consider the possibility that the world is not
filled with numerical wizards; most programmers I've
met are not that savvy about machine FP, and are unlikely
to correctly use any of the knobs intended for controlling
FP code.  Given the desire to have bit-for-bit compatibility,
I think that Sun's original choice for Java FP arithmetic
was the correct one, both because it yields least-surprising
results and because it has the most concise description.
That it happens to run well on Sparc merely means that 
Sun made the right choice twice.  (Improving transcendental
accuracy is fine with me, though it would be nice if some
reference source code were available.)

For access to fused-multiply-add, there is little need
to modify the existing system; simply write it portably
in Java, put it where anyone can get it, and on those systems
where it can replaced with a machine instruction, do the
obvious substitution.  We (NaturalBridge) would like to do
something similar for unsigned and word operations (we've
written the 100% Java implementation, and use it, but
haven't had the time to promote it to the rest of the world
or pattern-match the calls).  If programmers need the operation,
they can ask for it by name.  If they really like the existing
syntax, then calls to the appropriate method can be inserted
either with a source transformation or a bytecode transformation.
(The input pattern is simply "dmul; dadd", and the output
is "invokestatic SomeClass.fusedMultiplyAdd(DDD)D".  It does
add one byte to the code.)
This preserves portability, provides the instruction to
those people who want it, and eliminates differing-precision
surprises.

David Chase
NaturalBridge LLC