Source code for native methods in java

[kb]

Hey,

Where can I download the source code for the native methods in java
like the "floatToIntBits" method in Float.java?

Thanks
Kb

 

[Thomas Kellerer]

kb, 20.04.2009 13:59:

Hey,

Where can I download the source code for the native methods in java
like the "floatToIntBits" method in Float.java?

Thanks
Kb

Should be part of the OpenJDK source code

http://openjdk.java.net/

 

[Joshua Cranmer]

Where can I download the source code for the native methods in java
like the "floatToIntBits" method in Float.java?

You can get the definition of it in the upcoming Java 7 from OpenJDK:
<http://hg.openjdk.java.net/jdk7/jdk7/jdk/>.

Given some of the documentation somewhere on Sun's site, the
implementation itself is not surprising:

union {
int i;
float f;
} u;
u.f = (float)v;
return (jint)u.i;

 

[Joshua Cranmer]

Seriously? What if the native representation of floats isn't IEEE
754?

Well, OpenJDK only works on x86 and SPARC, as far as I can tell, so I
don't think it's an issue.

 

[Tom McGlynn]

Seriously? What if the native representation of floats isn't IEEE
754?

I'd be curious to know if there are any conformant Java
implementations on non-IEEE machines and if so how they handle
floating point. My sense of the standard is that the implementation
would have to emulate IEEE arithmetic on such machines. So even if the
native floating point numbers were not IEEE, the Java implementation
might choose to use an IEEE representation for its floating point
since it couldn't use the native floating point anyway.

Regards,
Tom McGlynn

 

[Mike Schilling]

I'd be curious to know if there are any conformant Java
implementations on non-IEEE machines and if so how they handle
floating point. My sense of the standard is that the implementation
would have to emulate IEEE arithmetic on such machines. So even if
the
native floating point numbers were not IEEE, the Java implementation
might choose to use an IEEE representation for its floating point
since it couldn't use the native floating point anyway.

Java almost certainly would. The C compiler, which would process that
bit of native code, almost certainly would not.

 

[Joshua Cranmer]

Java almost certainly would. The C compiler, which would process that
bit of native code, almost certainly would not.

I think in such circumstances, you would have some type which would have
the IEEE layout in the C portions of your program--say ieeefloat. If you
changed the float here to be that type, it would still work.

 

[Arne Vajhøj]

I'd be curious to know if there are any conformant Java
implementations on non-IEEE machines and if so how they handle
floating point. My sense of the standard is that the implementation
would have to emulate IEEE arithmetic on such machines. So even if the
native floating point numbers were not IEEE, the Java implementation
might choose to use an IEEE representation for its floating point
since it couldn't use the native floating point anyway.

Performance of an emulated floating point would be rather bad.

So I would expect:

no IEEE FP in HW => no Java SE

(I believe some of the Java ME standard allows no FP)

I have never seen a Java SE on a system without IEEE FP in HW.

Digital/Compaq did not implement Java on VMS VAX for that reason.

Arne

 

[John B. Matthews]

On Apr 20, 8:47 am, "Mike Schilling" <[email protected]>
wrote: [...]

Seriously? What if the native representation of floats isn't
IEEE 754?

I'd be curious to know if there are any conformant Java
implementations on non-IEEE machines and if so how they handle
floating point. My sense of the standard is that the implementation
would have to emulate IEEE arithmetic on such machines. So even if
the native floating point numbers were not IEEE, the Java
implementation might choose to use an IEEE representation for its
floating point since it couldn't use the native floating point
anyway.

This delightful implementation runs on 8-bit 6502. It uses 32-bit
floats and executes bytecode cross-compiled with javac. I'm guessing it
is not conformant:

<http://sourceforge.net/projects/vm02/>
<http://vm02.cvs.sourceforge.net/viewvc/vm02/vm02/src/java/lang/Float.java>
<http://vm02.cvs.sourceforge.net/viewvc/vm02/vm02/src/apple2/vm02.java>
<http://vm02.cvs.sourceforge.net/viewvc/vm02/vm02/src/apple2/vm02.clasm>

<code>
import apple2.*;

public class Example {

public static void main(String args[]) {
System.out.println("Hello, world!");
float pi = 355f / 113f;
System.out.println("pi ~ " + pi);
}
}
</code>

<console>
Hello, world!
pi ~ 3.1416
</console>

 

[Mike Schilling]

For a plain Java SE from Sun and a system really lacking hardware
support for IEEE FP, you may use one of these NexGen 5x86 chips;
those
were Pentium-compatible CPU of the mid-nineties, but lacking a FPU.
I
saw some of those running. Linux runs fine on them, and Linux knows
how to emulate a FPU for them. Basically, every FP opcode triggers
an
exception, and the kernel uses a software emulator to compute the
proper result. Since those 5x86 chips are otherwise
Pentium-compatible, a plain Java SE binary from Sun should run fine
on them (albeit quite slowly by today's standards).

Of course, a kernel trap is very expensive, so the "five times
slower"
above becomes more of a "twenty times slower", but still, it works.

A JVM optimized for this chip could do better, of course, by calling
the FP routines directly instead of trapping (and being *very* careful
not to JIT anything that does floating point :