This is the mail archive of the java@gcc.gnu.org mailing list for the Java project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Java floating-point mess


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]