Re: libgcj and ARM systems...

[Andrew Haley <aph at pasanda dot cygnus dot co dot uk>]

> Date: Wed, 17 May 2000 16:20:58 -0400
> From: Scott Bambrough <scottb@netwinder.org>
> 
> I would enter a bug for these in the bug tracking system so others
> know a problem exists.  I'll try to work on patches for these next
> week.

Ah yes, ARM's famous middle-endian floating-point format.  libgcj
needs some porting.

> union {
>   jlong l;
>   jdouble d;
> };
> 
> A union like the above is declared in several places in these files.
> Should this be moved to a header and used in a consistent manner in
> these files?

isNaN and its friends are correct as long as the float<->integer
conversion routines are correct.  These conversions need ARM versions.

I suggest that a right thing to do is to create static inline
conversion functions (called something like _Jv_floatToIntBits etc)
and put them in a common header file.  There's no need for any
routines other than these conversion routines to use unions, and on
some ports it may be best to use some other means than a union (for
example an linline asm) to do the conversion, so it's good not to
expose the use of a union to other files.

It's worth checking the fdlibm routines to see if there are any
ARM-related problems there.  If there are, it's more important to make
sure that we have ARM-compatible versions of the fdlibm files, and any
patches need to go into fdlibm.  This is important: if we diverge from
fdlibm we'll store up problems for the future.

> If so which header?  Something similar appears in include/jvm.h as
> _Jv_word2.

That file doesn't seem like a bad choice.

Andrew.