This is the mail archive of the
mailing list for the Java project.
Re: Don't optimize by hand (Was Re: Lack of fabsf on Solaris(patch included))
> > Here is a test program.
> > If the Java runtime is compliant with the strictfp specification,
> > you will see the following:
> > % java StrictfpTest
> > shuJIT for Sun Classic VM/x86 by Kazuyuki Shudo
> > 1.112808544714844E-308 (0x0008008000000000)
> > * 1.0000000000000002 (0x3ff0000000000001)
> > default : 1.112808544714844E-308 (0x8008000000000)
> > strictfp: 1.1128085447148447E-308 (0x8008000000001)
> > 2.225073858507201E-308 (0x000fffffffffffff)
> > / 0.9999999999999999 (0x3fefffffffffffff)
> > default : 2.2250738585072014E-308 (0x10000000000000)
> > strictfp: 2.225073858507201E-308 (0xfffffffffffff)
> Not necessarily: non-strict FP can be exactly the same as strict FP at
> the implementor's discretion.
Yes. Non-strict FP results do not have to be the same as
the above (default:). But, the above `strictfp:'
results are necessary if the Java runtime is compliant
to the strictfp, which is part of the JLS.
Actually, most JVMs don't implement the strictfp. Even
Sun and IBM do not. I suppose the demand is pretty
small. I know only few implementations, that are
BulletTrain a static compiler and shuJIT a JIT compiler.
> In this case the question is, are the values GCJ returns incorrect?
> If so, we have a bug in GCJ or in the FPU itself.
I have tried only a little old GCJ, which says,
gcc version 2.95.2 19991024 (release).
It just does not implement the strictfp.
> I know I should do this calculation by hand to make sure, but...
We don't have to calculate by hand. Other processors
like SPARC and PowerPC than x86 complies with the strict
FP semantics by nature. So we can see the calculation
result which strictfp should generate with such
processors. Note that we may have to be sure that
optimizations related to FP operations are not applied
when try to see the strict results. I guess bytecode
interpreter and C program compiled with the -O0 switch
are good for that purpose.
Kazuyuki SHUDO Happy Hacking!
Muraoka Laboratory, Waseda University