1. Re: power() (short)
Rolf Schroeder writes:
> I found that the example line:
>
> printf(1,"%24.16e\n", power(10,300)*power(10,-300) )
>
> returns under exw.exe with IEEE accuracy, whereas
> it returns under ex.exe only with 14 significant digits.
Yes, that's what I said yesterday.
It also works nicely on Linux and FreeBSD.
Only DOS (ex) is at issue here.
> Are there really two different fpc-WATCOM-libs, one for DOS, one for Win32?
I don't compile exw.exe using /fpc. It isn't necessary, because
if you don't have f.p. hardware, f.p. instructions will trap (jump)
into software emulation routines contained in Windows (but not in DOS).
> Or could it be that for some reason the CauseWay extender avoids
> calling the hardware fpu? Is there with respect to causeway possibly
> a parameter to set (for compilation) to force the use of the fpu if present?
Causeway has nothing to do with it.
The /fpc compile option and the SET NO87=1 run-time option
are provided by WATCOM C to deal with the problem that
old 486 and 386 computers don't necessarily have support
for f.p. instructions. With the Pentium and later CPUs all machines
support f.p. instructions. I could build a version of ex.exe without
the /fpc option, and it would likely give you the same accuracy
and speed as exw.exe. I just don't want to have two different
ex.exe's to build and maintain. On f.p. intensive programs
the speed difference between ex and exw is only about 20%.
Note that with /fpc, the hardware f.p. is still used if available,
but there is the extra overhead of a subroutine call and a test,
and I believe that there can also be a loss in precision, since
intermediate results are likely saved into 64-bit C double variables,
during these calls, whereas in-line f.p. instructions will keep the
data in 80-bit internal f.p. registers on the CPU.
Now, (if you are still reading this), there is yet another f.p. option
for DOS. I used to (back in version 1.0 and 1.1) compile with
a WATCOM option that generated in-line f.p. instructions,
while including a software emulation library for all f.p. instructions.
If the CPU supported f.p. instructions, they would run just like exw
does now. If the CPU did not support f.p., then an exception would
occur whenever an f.p. instruction was encountered. This exception
would be caught, and the appropriate software emulation routine
would be called. With this approach, intense f.p. calculations
on a machine with f.p. hardware will be 20% faster than now,
and maybe a bit more accurate, while f.p. calculations on
machines without f.p. hardware will be 3 or 4 times slower than
they are now (the exception handling is expensive.)
ex.exe will also be larger, but only by 8K or so I believe.
Translated/compiled Euphoria code would see a bigger speed increase
since there is less overhead.
I'll consider going back to this method, since very few people
are lacking f.p. hardware these days.
Regards,
Rob Craig
Rapid Deployment Software
http://www.RapidEuphoria.com
