> 
>  Hi,
> 
> thanks for your replies.
> I got it basically working, except I am not able to properly return
> and print floats and doubles.  Actually, I'm returning them just fine,
> but the Java libraries (which implement their own double->ascii
> conversion) can't print them, complaining that "133" is an excessively
> large digit. (The number it's trying to print is 133.6)
> The libraries use a native function to obtain the bit layout of a double,
> which is invoked.
> 
> So, three short questions:
> 
> * Does the arm software floating point emulation use IEEE-754?
> 
>     In particular, I need to implement a function that turns a double number
>     into its IEEE 754 floating-point "double format" bit layout, where
>     Bit 63 represents the sign of the floating-point number.  Bits 62-52 
>     represent the exponent.  Bits 51-0 represent the significand (sometimes 
>     called the mantissa) of the floating-point number.

The ARM fully implements IEEE floating point, though normally this is done 
with software emulation rather than with hardware.

My guess is that you are making the same assumption that many people make 
that because the ARM is running little-endian the exponent of a double 
will be in the high word.  In fact the exponent is in the lower word.  You 
can find full details of how the ARM lays out floating point numbers in 
the ARM7500FE data sheet (http://www.arm.com/Documentation/UserMans/PDF/ARM
7500.html) -- in particular you want chapters 8, 9 and 10 (which are in 
File5).

> 
> * Is it correct to implement this function like so:
> 
>     long long doubleToLongBits(double val) { return *(long long *)&val; }

Yes, that should work, though it's clearly non-portable.  A cleaner, if 
windy, implementation might be

long long doubleToLongBits(double val)
{
  union {
    long long l;
    double d;
  } x;
  x.d = val;
  return x.l;
}

(I've just checked and gcc can completely optimize this away).

> 
> * Do long longs work as advertised in NetBSD/arm32 or are there any known
>   caveats?

Yes and No respectively.

Richard.