Re: Java floating-point mess

Re: Java floating-point mess

[Zack Weinberg]

On Thu, Apr 04, 2002 at 06:56:15AM -0500, Robert Dewar wrote:
> <<The Java front end has a number of places that assume not only that
> the host and target floating point formats are identical, but that
> both are IEEE.  I've tried to get rid of them, but run afoul of its
> not being possible to link real.o into gcjh -- it wants to drag in
> most of the back end.
> >>
> 
> Presumably the complaint is about assuming that the host fpt format is
> IEEE, the target fpt format presumably MUST be IEEE, since this is required
> by Java, no?

Well, the Java front end doesn't appear to take any special care to
ensure that SFmode is IEEE single and DFmode double.  (We'd have to
have a floating point emulator library built into libjava that
implemented IEEE fp, to get it right for non-IEEE targets.)  But yes,
the code I'm looking at right now is only for the host side.

Thinking out loud... The major problem is with gjavah, which wants to
read in a .class file and print out things like

const jdouble pi = 3.1415926... ;

which are then going to be interpreted by the C++ compiler -- come to
think of it, there is no way to win here on a non-IEEE target.
Ignoring the language spec and using the target's floating point,
whatever it happens to be, might be the sanest thing to do from an
interoperability standpoint.

I think I can get around the immediate problem by using C99
hexadecimal floating-point constants.

[I should have cc:ed java@ from the beginning -- the original message
is at http://gcc.gnu.org/ml/gcc/2002-04/msg00135.html if anyone's
interested.]

zw

Re: Java floating-point mess

[Andrew Haley]

Zack Weinberg writes:
 > On Thu, Apr 04, 2002 at 06:56:15AM -0500, Robert Dewar wrote:
 > > <<The Java front end has a number of places that assume not only that
 > > the host and target floating point formats are identical, but that
 > > both are IEEE.  I've tried to get rid of them, but run afoul of its
 > > not being possible to link real.o into gcjh -- it wants to drag in
 > > most of the back end.
 > > >>
 > > 
 > > Presumably the complaint is about assuming that the host fpt
 > > format is IEEE, the target fpt format presumably MUST be IEEE,
 > > since this is required by Java, no?
 > 
 > Well, the Java front end doesn't appear to take any special care to
 > ensure that SFmode is IEEE single and DFmode double.  (We'd have to
 > have a floating point emulator library built into libjava that
 > implemented IEEE fp, to get it right for non-IEEE targets.)  But yes,
 > the code I'm looking at right now is only for the host side.
 > 
 > Thinking out loud... The major problem is with gjavah, which wants to
 > read in a .class file and print out things like
 > 
 > const jdouble pi = 3.1415926... ;
 > 
 > which are then going to be interpreted by the C++ compiler -- come to
 > think of it, there is no way to win here on a non-IEEE target.

Right -- Java requires that the target FP format be IEEE.  We don't
support Java on non-IEEE targets.  We can solve any build problems by
not building Java on hosts that are non-IEEE.

The only issue here is that we won't be able to cross-compile Java on
a VAX or somesuch, isn't it?  Or am I missing something here?

Andrew.

Re: Java floating-point mess

[Robert Dewar]

<<The front end is required to do these computations in some contexts,
namely compile-time constants.  This is a concern to us, but it isn't
immediately pressing.  We already violate the spec with respect to
compile-time constants in several ways.
>>

Sure, of course I understand that, but these computations should be done
using simulated IEEE arithmetic rather than host arithmetic.

Re: Java floating-point mess

[Tom Tromey]

>>>>> "Robert" == Robert Dewar <dewar@gnat.com> writes:

Andrew> The only issue here is that we won't be able to cross-compile
Andrew> Java on a VAX or somesuch, isn't it?  Or am I missing
Andrew> something here?

Robert> That sounds right provided that the front end is not trying to
Robert> use host floating-point arithmetic to precompute expressions
Robert> (IEEE is not nearly enough of an absolute standard for this to
Robert> give the right results in all cases).

The front end is required to do these computations in some contexts,
namely compile-time constants.  This is a concern to us, but it isn't
immediately pressing.  We already violate the spec with respect to
compile-time constants in several ways.

Tom

Re: Java floating-point mess

[Robert Dewar]

<<The only issue here is that we won't be able to cross-compile Java on
a VAX or somesuch, isn't it?  Or am I missing something here?
>>

That sounds right provided that the front end is not trying to use host
floating-point arithmetic to precompute expressions (IEEE is not nearly
enough of an absolute standard for this to give the right results in
all cases).